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ABSTRACT 


Public  key  infrastructure  (PKI)  was  created  to  provide  the  basic  services  of 
confidentiality,  authenticity,  integrity  and  non-repudiation  for  sensitive  information  that 
may  traverse  public  (un-trusted)  networks.  This  thesis  provides  a  brief  description  of  the 
background  and  functional  components  of  a  PKI,  and  then  “builds”  a  PKI  to  be  used  for 
research  at  the  Naval  Postgraduate  School  (NPS).  Deficiencies  of  this  PKI  with  respeet  to 
DoD  PKI  policy  are  delineated.  The  thesis  addresses  details  of  software  selection, 
installation,  configuration  and  operation;  using  Netscape’s  Certificate  Management 
System  as  its  Certifieate  Authority  applieation  of  choiee.  The  funetionality  of  this  PKI 
was  validated  by  testing  all  major  certificate  life-cycle  events  (ereation,  archival, 
revocation,  validation,  etc.)  All  but  two  of  these  tests  were  sueeessful — ^key  escrow  and 
revocation  checking — and  thus  these  two  remain  to  be  addressed  by  further  work  to  make 
the  NPS  PKI  fully  funetional. 
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I.  INTRODUCTION 


A.  BACKGROUND 

Gone  are  the  days  are  in  whieh  human  beings  correspond  via  carrier  pigeons, 
telegraphs,  railroads,  telephones  and  the  Postal  Service.  In  today’s  society,  people  are 
demanding  immediate  data  exchange  most  likely  provided  by  the  Internet.  Since  its 
invention  in  the  late  1950’s,  the  Internet  has  become  a  global  focal  point  on  which  people 
rely  for  personal,  business,  and  even  military  use.  In  each  arena,  from  personal  to  military 
use,  it  is  vital  that  the  data  exchange  be  conducted  in  a  secure  environment.  Thus,  the 
introduction  of  Public  Key  Infrastructure  (PKI),  which  is  a  promising  new  technology  to 
support  the  secure  exchange  of  data  over  the  Internet.  PKI  can  support  a  wide  variety  of 
Internet  applications  including  electronic  mail,  virtual  private  networks,  secure  web 
access  and  custom  applications.  It  allows  a  sender  to  “sign”  data  digitally,  and  for  the 
recipient  to  verify  the  originator  of  the  data  and  to  ensure  the  data  has  not  been  modified 
without  the  recipient’s  knowledge.  PKI  provides  the  user  with  four  basic  security 
services:  confidentiality,  integrity,  authenticity  and  non-repudiation. 

In  today’s  society,  these  information  security  services  are  vital  to  the  performance 
of  any  organization  and  are  essential  services  required  by  the  Department  of  Defense 
(DoD)  as  it  engages  heavily  in  sensitive  communications.  The  DoD  has  taken  an 
aggressive  approach  in  establishing  a  PKI  that  promises  to  support  its  diverse  set  of 
missions  and  operations.  “The  implementation  of  PKI  in  the  DoD  will  enhance  military 
operations  in  the  tactical,  joint,  and  combined  operational  environments,  as  well  as 
improved  interoperability  with  allies,  coalition  forces,  civil  agencies,  and  business 
partners.”!  This  will  ensure  operational  effectiveness  when  U.S.  forces  participate  in 
ongoing  campaigns  to  promote  democracy,  defend  American  sovereignty,  liberate 
countries  and  combat  terrorism. 

B,  STATEMENT  OF  PROBLEM 

A  Public  Key  Infrastructure  (PKI)  is  a  core  enabler  for  more  secure 
communications  in  a  computer  network  environment.  It  is  defined  as  an  infrastructure  for 

1  DoD  Public  Key  Infrastructure  Program  Management  Office,  “PKI  Roadmap  for  the  DoD,  Version 
5.0,”  December  18,  2000. 
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establishing  a  secure  method  for  exchanging  digital  information.  It  is  a  combination  of 
cryptographic  methods  and  software  that  integrates  the  use  of  digital  signatures,  digital 
certificates  and  certificate  authorities  into  a  network  security  architecture  capable  of 
managing  the  process.  Properly  implemented  and  managed,  a  PKI  can  provide  the 
necessary  mechanism  whereby  ah  the  information  assurance  attributes  of  confidentiality, 
integrity,  authenticity  and  non-repudiation  can  be  achieved.  The  success  of  any  PKI  is 
primarily  determined  by  the  answers  to  three  questions:  1)  How  trustworthy  is  the 
binding  of  the  declared  identity  in  a  certificate  with  that  of  its  associated  public  key?  2) 
How  well  are  private  keys  kept  safe  from  misuse?  3)  Is  the  strength  of  the  certificate 
validation  checking  mechanism  sufficient? 

In  1997,  the  Deputy  Defense  Secretary,  Dr.  John  Hamre,  exhorted  that  the  DoD 
would  provide  a  solid  foundation  for  information  assurance  capabilities  across  ah  its 
Departments  consistent  with  its  operational  imperatives  and  missions.  He  announced  a 
new  DoD  policy  encouraging  the  widespread  use  of  PKI  to  facilitate  a  paperless 
organization  and  to  provide  secure  communications.  Later,  DoD  mandated  that  ah  its 
infrastructures  be  prepared  to  issue  and  use  Class  3  certificates  by  October  2002. 
Currently,  the  DoD  Chief  Information  Officer  (CIO)  has  amended  this  requirement  to 
read  ah  sites  will,  “continue  to  work  towards  achieving  these  important  milestones,  as 
soon  as  possible. ”2  This  amendment  was  due  to  a  DoD-wide  failure  to  implement  the 
myriad  of  infrastructure  components  required  to  achieve  this  overly  optimistic  milestone. 

The  DoD  is  seeking  help  from  within  its  own  organizations,  the  commercial 
sector,  and  research  organizations,  such  as  the  Naval  Postgraduate  School,  to  assist  in 
achieving  its  goal  of  Department-wide  PKI  usage. 

1.  Scope  and  Assumptions 

The  purpose  of  this  proposed  thesis  work  is  to  create  a  test  PKI  for  research  use  at 
the  Naval  Postgraduate  School.  The  goal  will  be  to  implement  the  PKI  using 
commercially  available  products  and  services  so  that  it  is  as  close  to  DoD  compliance  as 
possible  given  the  constraints  of  the  NPS  physical  facilities  and  research  money 
available.  The  PKI  prototype  will  integrate  DoD  compliant  devices,  services  and 

2  DoD  Chief  Information  Officer  Memorandum,  “DoD  PKI  Milestones  Update,”  October  7,  2003. 
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technologies  into  a  fully  functional  CA.  A  PKI  test  facility  available  on-site  at  NPS  will 
enable  ensuing  faculty  and  thesis  students  to  conduct  further  research  into  the  DoD’s 
most  provocative  questions  to  make  their  goal  of  Department-wide  PKI  usage  a  reality. 

C.  RESEARCH  OBJECTIVES 

1.  Primary  Research  Question 

•  How  to  implement  a  Certificate  Server  and  its  supporting 
certificate  issuance,  archival,  revocation  and  validation 
infrastructure? 

2.  Subsidiary  Research  Questions 

•  What  are  all  the  functional  components  of  a  CA? 

•  What  are  DoD’s  specified  administrative  and  policy  requirements 
concerning  operating  a  CA? 

•  What  are  the  infrastructure  facility  deficiencies  of  the  NPS  CISR 
CA  labs  that  may  preclude  it  from  being  in  full  compliance  with  a 
DoD-compliant  CA? 

•  What  are  the  technical  requirements  regarding  the  operation  of  a 
CA  server  and  its  supporting  issuance,  archival,  revocation,  and 
validation  infrastructure? 

•  What  hardware  is  necessary  to  implement  a  fully  functional  CA? 

•  What  software  is  necessary  to  implement  a  fully  functional  CA? 

•  What  is  the  proper  communicative  interaction  between  the  Local 
Registration  Authority  (LRA)  server,  the  Registration  Authority 
(RA)  server,  the  Certificate  Authority  (CA)  server,  the  certificate 
archival  directory,  and  the  revocation  and  validation 
servers/services? 

•  What  are  the  proper  means  for  registering  PKI  certificate  owners? 

•  What  are  the  proper  means  for  making  certificates  available  to  the 
user  community? 

•  What  is  the  proper  means  for  maintaining  archives  of  inactive 
certificates  and  keys? 

•  What  is  the  proper  means  for  maintaining  a  private  key  recovering 
agent  (KRA)? 

•  What  is  the  proper  means  for  supporting  certificate  revocations 
that  may  occur  for  reasons  other  than  normal  certificate  expiration? 

•  What  are  the  proper  means  for  providing  a  mechanism  for  users  of 
the  CA’s  certificate  to  assess  the  current  validity  status  of  those 
certificates? 
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•  What  should  be  included  in  a  CA  Users’  Manual  that  would 
facilitate  on-going  operations  of  the  test  CA? 

D,  ORGANIZATION 

This  thesis  is  composed  of  six  chapters  and  an  appendix. 

Chapter  I:  Introduction  -  This  chapter  introduces  the  topic  of  Public  Key 
Infrastructure  (PKI)  and  discusses  the  benefits  of  having  a  PKI  available  for  testing  at  the 
Naval  Postgraduate  School. 

Chapter  II:  What  is  PKI?  -  This  chapter  provides  an  overview  of  PKI  to  include 
its  components  and  related  products  and  services. 

Chapter  III:  Naval  Postgraduate  School’s  Center  for  Information  Systems 
Security  Studies  and  Research  (CISR)  Lab  -  This  chapter  provides  a  broad  overview  of 
the  NPS  CISR  lab,  to  include  deficiencies  of  the  lab  in  meeting  DoD  CA  requirements 
and  what  adjustment  would  need  to  occur  for  the  lab  to  be  in  compliance  with  those 
requirements. 

Chapter  IV:  Selection  of  Equipment  and  Software  -  This  chapter  outlines  the 
choice  of  hardware  and  software  utilized  to  implement  the  test  PKI  and  an  inter¬ 
component  functional  overview  of  the  software. 

Chapter  V:  Validation  of  Certificate  Life-Cycle  Functionality  -  This  chapter 
describes  the  results  from  the  certificate  life-cycle  tests  performed  to  validate  the  PKI 
performance. 

Chapter  VI:  Conclusion  -  This  chapter  summarizes  the  main  ideas  presented  in 
the  previous  chapters,  stating  observations  and  issues  experienced  in  the  completion  of 
the  thesis,  and  suggesting  potential  areas  for  continued  research  on  this  topic. 

Appendix:  User’s  Guide  -  This  guide  has  two  parts.  The  first  is  a  basic 
installation  guide  of  the  software  and  hardware  utilized  to  construct  the  test  PKI  facility. 
The  second  provides  the  user  with  instructions  and  diagrams  for  all  tasks  required  for 
certificate  management. 
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II.  WHAT  IS  PKI? 


A,  CRYPTOGRAPHY 

Public  Key  Infrastructure  has  its  early  roots  in  eryptography,  which  can  be  traced 
to  Julius  Caesar’s  reign  over  Rome.  The  Webster  dictionary  defines  eryptography  as  the 
enciphering  or  deciphering  of  messages  in  secret  code  or  cipher.  To  encipher  data  is  to 
take  plaintext  to  an  unreadable  text  and  decipher  it  to  reverse  the  process  back  to 
comprehensible  text.  Data  is  often  enciphered  to  prevent  eavesdropping  so  that  an 
unlikely  recipient  cannot  interpret  the  captured  information.  The  two  basic  forms  of 
cryptography  are  symmetric  and  asymmetric.  A  symmetric  cryptographic  algorithm 
applies  the  same  key  for  eneryption  and  deeryption.  Whereas  Diffie  and  Heilman 
introduced  asymmetric  cryptography  in  the  late  1970’s3,  whieh  became  the  basis  for  PKI. 
Asymmetric  cryptography  utilizes  two  mathematically  related  keys  to  eneipher  and 
decipher  data. 

B,  PKI  DEFINED 

The  DoD  defines  PKI  as,  “the  combination  of  software,  encryption  technologies, 
and  services  that  enables  enterprises  to  protect  the  security  of  their  communication  and 
business  transaetions  on  networks. ”4  Most  importantly,  PKI  permits  users  with  no 
preexisting  relationship  to  communicate  seeurely  regardless  of  the  distance  between  them 
through  a  commonly  shared  certificate  “chain  of  trust”.  PKI  allows  an  organization  to 
enjoy  the  basic  services  of  confidentiality,  data  integrity,  identity  and  authenticity  and 
non-repudiation.  The  National  Institute  of  Standards  and  Teehnology  (NIST)  define  these 
services  as:5 

Confidentiality  services  restriet  access  to  the  content  of  sensitive  data  to 
only  those  individuals  who  are  authorized  to  view  the  data.  Confidentiality 
measures  prevent  the  unauthorized  disclosure  of  information  to 
unauthorized  individuals  or  processes. 


3  Whitfield  Diffie  and  Martin  Heilman,  “New  Directions  in  Cryptography,”  IEEE  Transactions  on 
Transformation  Theory  22,  pp.  644-654,  1976. 

4  Defense  Information  Systems  Agency,  “DoD  Public  Key  Infrastructure  Introduction,” 
lhttp://iitc. fhu.disa.mil/pki/intro.html1.  January  12,  2004.  Accessed  June  2004. 

3  National  Institute  of  Standards  and  Technology,  “Introduction  to  Public  Key  Technology  and  the 
Federal  PKI  Infrastructure,”  February  26,  2001. 
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Data  Integrity  services  address  the  unauthorized  or  accidental  modification 
of  data.  This  includes  data  insertion,  deletion,  and  modification.  To  ensure 
data  integrity,  a  system  must  be  able  to  detect  unauthorized  data 
modification.  The  goal  is  for  the  receiver  of  the  data  to  verify  that  the  data 
has  not  been  altered. 

Identification  and  authentication  services  establish  the  validity  of  a 
transmission,  message,  and  its  originator.  The  goal  is  for  the  receiver  of 
the  data  to  determine  its  origin. 

Non-repudiation  services  prevent  an  individual  from  denying  that  previous 
actions  had  been  performed.  The  goal  is  to  ensure  that  all  the  recipients  of 
the  data  is  assured  of  the  sender’s  identity. 

These  services,  combined  with  an  organization’s  desire  to  enhance  the  security  of 
their  data  and  to  minimize  the  amount  of  paper  generated  by  their  organization,  has  given 
momentum  to  the  use  of  PKI,  which  is  essential  to  an  organization’s  growth.  Any 
enterprise  intending  to  maximally  leverage  use  of  the  Internet  should  strongly  consider 
utilizing  PKI.  Due  to  the  various  commercial  products  and  configurations  available,  a 
committee  was  formed  to  generate  a  standard  for  implementing  PKI  and  its  related 
products  and  services.  The  PKIX  (PKI  X.509)  working  group  was  formed  in  September 
1995  to  establish  and  develop  Internet  standards  to  support  an  X.509-based  PKI.  Today, 
the  X.509  standard  is  widely  accepted  and  PKIX  has  produced  several  informational  and 
standard  track  documents  in  support  of  PKI. 6  This  thesis  will  make  frequent  reference  to 
the  X.509  guidelines  and  achievements. 

C.  DIGITAL  SIGNATURES 

The  DoD  policy  states  that  users  who  have  the  capability  to  sign  emails  digitally 
must  always  do  so  after  1  October  2002.7  The  user  can  configure  a  workstation  to  sign 
and  encrypt  documents  automatically.  The  enciphering  of  data  ensures  the 
confidentiality  of  the  information  sent  over  the  worldwide  web.  Digital  signatures 
provide  for  the  remaining  services  of  data  integrity,  authentication  and  non-repudiation. 
Public  key  cryptography  involves  the  public  distribution  of  an  encryption  key  string,  or 
public  key,  to  the  intended  recipients  of  data.  The  sender  will  maintain  his  private  key  in 
a  secure  location. 

6  Internet  Engineering  Task  Force,  “Public-Key  Infrastructure  (X.509)  (pkix),” 
rhttp://www.ietforg/litml.charters/pkix-charter.html1.  May  18,  2004.  Accessed  June  2004. 

7  Arthur  Money,  “DoD  PKI  Policy  Memorandum,”  August  12,  2000. 
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A  digital  signature  generation  process  is  begun  by  sending  the  original  data 
through  a  “one  way  hash  algorithm.”  A  hash  algorithm  produces  an  unreadable, 
condensed  version  of  the  original  message,  called  a  message  digest,  by  using  one  of  the 
listed  hash  algorithms; 8 

•  MD5  is  a  128-bit  message  digest  function  developed  by  Ron  Rivest. 

•  SHA-1  is  a  hashing  algorithm  similar  in  structure  to  MD5,  but  produces  a 
digest  of  160  bits  (20  bytes).  Due  to  the  large  digest  size,  it  is  less  likely 
that  two  different  messages  will  have  the  same  SHA-1  message  digest.  For 
this  reason,  SHA-1  is  preferred  to  MD5. 

•  HMAC  is  a  hashing  method  that  uses  a  key  in  conjunction  with  an 
algorithm  such  as  MD5  or  SHA-1.  Thus,  it  is  possible  to  refer  to  HMAC- 
MD5  and  HMAC-SHAl. 

The  message  digest  is  then  encrypted  using  the  sender’s  private  key,  thus  creating 
the  digital  signature.  The  message  and  the  digital  signature  are  then  sent  to  the  recipient. 
The  recipient  must  then  verify  the  digital  signature.  She  starts  this  by  hashing  the 
received  message  using  the  same  hash  algorithm  the  sender  did.  The  recipient  uses  the 
sender’s  public  key  from  the  sender’s  certificate  to  decrypt  the  digital  signature  (the 
encrypted  message  digest)  that  was  sent  with  the  message.  If  the  message  digests  are 
identical  than  the  digital  signature  has  been  verified.  The  verified  digital  signature 
assures  the  recipient  that  the  message  was  sent  from  the  rightful  sender,  data  authenticity, 
and  that  data  has  not  been  altered,  data  integrity.  These  steps  are  completed  by  the  CMS, 
and  are  therefore  transparent  to  the  users.  The  process  of  digital  signing  and  verification 
appears  in  Figure  1. 


8  Cryptography  World,  “The  Cryptography  Guide,”  rhttp://www.ervptographvworld.eom/algo.htm1. 
2003.  Aeeessed  June  2004. 
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Figure  1.  Digital  Signature  Proeess9 


This  proeess  ean  be  very  eonfusing  as  to  what  key  to  use  when  and  for  what 
reason  and  by  whom.  Therefore,  Table  1  summarizes  whieh  key  to  use. 


Key  Function 

Key  Used 

Key  Owner 

Enerypt  data 

Publie  key 

Reeeiver 

Sign  data 

Private  key 

Sender 

Deerypt  data 

Private  key 

Reeeiver 

Verify  Signature 

Publie  key 

Sender 

Table  1.  Deseription  of  Key  Employment. 


9  Digital  Signature  Trust,  “PKI  Basics  Digital  Signatures  and  Public  Key  Infrastructure  (PKI)  101,” 
lhttp://wwwdigitalsignaturetrust.cotn/support/pki  basics.htmll.  Accessed  June  2004. 
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D,  FUNCTIONAL  COMPONENTS 

The  next  seetion  focuses  on  the  components  of  the  PKI  architecture.  PKI 
provides,  “the  framework  and  services  that  provide  for  the  generation,  production, 
distribution,  control  and  accounting  of  public  key  certificates. ”io  It  unites  hardware  and 
software  components,  policies  and  procedures  in  such  a  way  as  to  be  able  to  zealously 
communicate  with  greatly  reduced  fear  of  compromise.  It  provides  the  user  with  the  basic 
services  of  confidentiality,  data  integrity,  non-repudiation  and  authenticity. 

Different  organizations  choose  to  configure  their  PKI  utilizing  the  various 
available  commercial  products.  The  PKI  should  be  tailored  to  the  organizational  needs  of 
an  enterprise.  Although  the  configuration  may  vary,  the  basic  components  remain  the 
same.  The  Internet  Engineering  Task  Force  (IETF)  Public  Key  Infrastructure  X.509 
(PKIX)  working  group  has  identified  several  formal  and  generic  models  of  a  certificate- 
based  architecture  utilizing  the  basic  components:  of  end  entity  (i.e.,  certificate  owner, 
and  user),  certificate  authority,  certificate  repository  and  registration  authority 
1.  End  Entity 

This  term  is  often  used  to  denote  the  personnel  aspect  of  PKI.  However,  it  also 
includes  devices  such  as  routers,  servers  or  other  entities  that  require  certificates  to  enable 
certificate  based  authentication  or  encryption.  Depending  on  the  organizational  standard, 
it  may  be  referred  to  as  the  end  user,  relying  party,  or  subscriber.  Regardless  of  the 
terminology  used,  the  end  entity  is  the  person  or  device  name  identified  in  the  subject 
field  of  the  certificate.  Once  enrolled,  the  end  entity  is  bound  to  the  public  key  contained 
in  the  certificate  and  identified  by  the  distinguished  name  contained  in  the  certificate.  A 
relying  party  is  included  as  a  component  in  some  PKI  infrastructures  as  an  end  entity. 
The  X.509  states: 

A  relying  party  is  the  entity  who,  by  using  another’s  certificate  to  verify 
the  integrity  of  a  digitally  signed  message,  to  identify  the  creator  of  a 
message,  or  to  establish  confidential  communications  with  the  holder  of 
the  certificate,  relies  on  the  validity  of  the  binding  the  Subscriber’s  name 
to  a  public  key.  A  relying  Party  may  use  information  in  the  certificate 
(such  as  certificate  policy  identifiers)  to  determine  the  suitability  of  the 
certificate  for  a  particular  use. 

10  Space  and  Naval  Warfare  Systems  Command  Information  Systems  Security  Information  Warfare 
Defense  Program  Management  Office,  “Department  of  Defense  Public  Key  Infrastructure  Primer,  Version 
3.0,”  18  June  2001. 
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2,  Certificate  Authority 

There  are  three  types  of  CA:  self  signed,  subordinate  and  root  CAs.  They  are 
defined  asTi 

•  Self-signed  CA.  In  a  self-signed  CA,  the  public  key  in  the 
certificate  and  the  key  used  to  verily  the  certificate  are  the  same. 

Some  self-signed  CAs  are  root  CAs. 

•  Subordinate  CA.  In  a  subordinate  CA,  the  public  key  in  the 
certificate  and  the  key  used  to  verify  the  certificates  are  different. 

The  process  where  one  CA  issues  a  certificate  to  another  CA  is 
known  as  cross-certification. 

•  Root  CA.  A  root  CA  is  a  special  class  of  CA,  which  is  trusted  by  a 
client  and  is  at  the  top  of  a  certification  hierarchy.  All  certificate 
chains  terminate  at  a  root  CA.  The  root  authority  must  sign  its  own 
certificates  because  there  is  no  higher  certifying  authority  in  the 
certificate  hierarchy. 

As  a  result  of  the  policies  associated  with  the  various  CAs,  organizations  publish 
Certification  Practice  Statements  (CPS)  to  determine  policy  standards  for  operating  CAs. 
A  CA  could  be  responsible  for  issuing  certificates  in  accordance  with  one  or  more 
certificate  policies  associated  with  the  aforementioned  CA  types.  The  X.509  states,  “A 
CA  is  responsible  for  all  aspects  of  the  issuance  and  management  of  a  certificate, 
including  control  over  the  registration  process,  the  identification  and  authentication 
process,  the  certificate  manufacturing  process,  publication  of  certificates,  revocation  of 
certificates,  and  re -key;  and  for  ensuring  that  all  aspects  of  the  CA  services  and  CA 
operations  and  infrastructure  related  to  certificates  issues.”  The  CA  is  the  core  element  of 
the  PKI,  and  it  creates,  signs,  stores  and  issues  certificates  to  end  entities.  A  CA  accepts  a 
certificate  request,  and  after  verification,  will  use  its  private  key  to  assign  a  digital 
signature  to  the  certificate.  The  signature  process  effectively  binds  the  end  entity’s  (i.e., 
the  certificate  owner’s)  identity  with  his/her  public  key  that  is  stored  within  the 
certificate.  Once  signed,  the  certificate  is  issued  to  the  end  entity. 


11  Microsoft,  “Microsoft  Windows  2000  Server,  Cryptography  and  PKI  Basics,”  2000. 
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3.  Repository 

A  repository  is  a  generic  term  used  to  denote  any  method  for  storing  certificates 
and  CRL’s  so  that  they  can  be  retrieved  by  the  end  entityi2.  A  certificate  authority  can  be 
configured  to  generate  a  certification  revocation  list  (CRL).  A  CRL  is  a  compilation  of 
certificates  revoked  prior  to  their  normal  expiration  date.  Certificates  are  revoked  due  to  a 
number  of  reasons,  such  as;  key  compromise,  CA  compromise,  termination  of 
employment,  or  change  of  identifying  information  in  the  certificate.  The  certificates  are 
listed  in  the  CRL  by  serial  number  and  are  time  stamped.  CRL’s  can  either  be  online,  in 
which  case  the  revocation  list  is  pulled  by  the  user,  or  offline,  in  which  case  the  CA 
pushes  the  revocation  list  to  one  of  its  directories.  The  online  version  utilizes  the  Online 
Certificate  Status  Protocol  (OSCP),  which  checks  the  status  of  certificates  without 
tasking  the  CA.  The  off-line  version  encompasses  the  subscriber  using  the  Lightweight 
Directory  Access  Protocol  (LDAP),  the  Hyper  Text  Transfer  Protocol  (HTTP),  or  the  File 
Transfer  Protocol  (FTP)  to  view  the  status  of  certificates  prior  to  authenticating  a 
certificate.  Each  of  these  standards  reduces  the  overhead  of  the  CA  by  off-loading  more 
of  the  CRL  functionality. 

4,  Registration  Authority 

The  RA  is  an  optional  component  that  can  assume  a  number  of  administrative 
functions  from  the  CA.13  Through  a  trusted  relationship  with  the  CA,  the  RA  can  initiate, 
renew  and/or  revoke  a  certificate  request.  The  RA  acts  as  the  middleman  between  the  CA 
and  trusted  agents  to  process  requests  for  enrollment,  renewal  and  revocation,  and  to 
sending  the  signed  request  to  the  certificate  manager  (CM).  It  will  then  distribute  the 
approved  request  from  the  CM  to  the  requesting  agent.  The  RA  cannot  issue,  renew,  or 
revoke  certificates,  nor  can  it  or  publish  CRL’s  as  those  functions  are  specific  to  the  CA. 

The  RA  can  be  used  for  added  protection  for  the  CM  by  placing  it  outside  the 
firewall.  The  RA  will  determine  if  the  request  is  from  a  trusted  agent  prior  to  sending  the 
request  to  the  CM  that  should  be  located  behind  the  firewall. 

Figure  2,  illustrates  the  high  level  activities  associated  with  the  PKI  without  the 
optional  RA  displayed. 

12  PKI  Forum,  “PKI  Basics  -  A  Technical  Perspective,”  November  2002. 

13  Ibid. 
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PKI  Process  Flow 


Figure  2.  PKI  Process  Flow  1 4 


Step  1 .  Subscriber  applies  to  Certification  Authority  for  Digital 
Certificate. 

Step  2.  CA  verifies  identity  of  Subscriber  and  issues  Digital  Certificate. 

Step  3.  CA  publishes  Certificate  to  Repository. 

Step  4.  Subscriber  digitally  signs  electronic  message  with  a  Private  Key  to 
ensure  Sender  Authenticity,  Message  Integrity  and  Non-Repudiation  and 
sends  to  Relying  Party. 

Step  5.  Relying  Party  receives  message,  verifies  Digital  Signature  with 
Subscriber's  Public  Key,  and  goes  to  Repository  to  check  status  and 
validity  of  a  Subscriber's  Certificate. 

Step  6.  Repository  returns  results  of  status  check  on  Subscriber's 
Certificate  to  Relying  Party. 

Now,  with  a  basic  understanding  of  the  components  in  the  PKI  provided.  Table  2 
depicts  some  common  tasks  associated  with  a  PKI  and  the  component  that  is  responsible 
for  implementing  each  task. 


14  Digital  Signature  Trust,  “PKI  Basics  Digital  Signatures  and  Public  Key  Infrastructure  (PKI)  lOI,” 
lhttp://www. digitaIsignaturetrust.com/support/pki  basics. htmll.  Accessed  June  2004. 
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Function 

Description 

Implementation 

Registering  users 

Collect  user  information,  verify 
identity 

Function  of  CA,  or  separate  RA 

Issuing  certificates 

Create  certificates  in  response  to 
user  or  administrator  request 

Function  of  the  CA 

Revoking  certificates 

Create  and  publish  Certificate 
Revocation  Lists  (CRTs) 

Administrative  software 
associated  with  the  CA 

Storing  and  retrieving 

Make  certificates  and  CRTs 
available  to  authorized  users 

Repository  for  certificates  and 
CRTs  in  secure  replicated 
directory  service  accessible  via 
LDAP 

Certificates  and  CRTs 

Impose  policy-based  constraints 
on  certificate  chain,  and  validate 
if  all  constraints  are  met 

Function  of  the  CA 

Policy-based  certificate  path 
validation 

Time-stamp  each  certificate 

Function  of  the  CA  or  a  dedicated 
Time 

Server  (TS) 

Key  lifecycle  management 

Update,  archive  and  restore  keys 

Automated  in  software  or 
performed  manually 

Table  2.  Pu 

dUc  Key  Infrastructure  (PKI)  Functions  i^ 

E.  CERTIFICATES 

A  public  key  certificate  is  a  digitally  signed  statement  that  binds  the  value 
of  a  public  key  to  the  identity  of  the  subject  (person,  device,  or  service) 
that  holds  the  corresponding  private  key.  By  signing  the  certificate,  the 
CA  attest  that  the  private  key  associated  with  the  public  key  in  the 
certificate  is  in  the  possession  of  the  subject  named  in  the  certificate.! 6 

A  certificate  provides  a  legally,  binding  exchange  that  cannot  refute  a  person’s 
identity.  The  recipient  of  the  data  is  assured  of  a  person’s  identity  by  the  CA  signing  of 
the  certificate.  Certificates  are  issued  across  CAs  and  are  assigned  by  classes  with 
different  assurance  levels  to  establish  a  hierarchy.  A  “chain  of  trust”  is  initiated  when  a 
CA  validates  a  user.  Trust  relationships  are  established  among  CAs,  by  issuing  cross 
certifications  forming  trusted  paths.  When  a  user  tries  to  validate  a  certificate  from  a  user 
outside  of  his  chain,  the  trusted  relationships  are  used  to  validate  that  certificate.  CAs 

15  Ray  Hunt,  “PKI  and  Digital  Certification  Infrastructure,”  rhttp://www.au- 
kbc  .org^pmain  1  /PKI/PKIieee  .pdfl .  2002.  Accessed  June  2004. 

16  Microsoft,  “Microsoft  Windows  2000  Server,  Cryptography  and  PKI  Basics,”  2000. 
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can  have  numerous  trust  relationships  established,  each  one  having  a  different  level  of 
assurance  associated  with  it.  The  assurance  levels  are  provided  as  follows:  Class  2 
certificates  are  intended  for  low  value  unclassified  information  in  a  moderately  protected 
environment.  Class  3  certificates  consist  of  class  2  assurances  in  addition  to  high  value 
and  discretionary  access  control  information  in  highly  protected  environments.  Class  4 
handles  unclassified  high  value  mission  critical  information  in  minimally  protected 
environments.  Class  5  is  reserved  for  high  value,  high-risk  environment  information.  The 
X.509  requires  a  person’s  identity  to  be  established  by  a  database,  supervisor  or 
subscriber  for  class  2-assurance  level.  It  requires  a  trusted  agent  to  physically  view  a 
valid  ID  for  class  3  and  4  assurances.  The  National  Security  Agency  (NSA)  determines 
class  5  assurance  level  requirements. 

This  thesis  involved  the  use  of  Netscape  software  to  build  the  prototype  PKI. 
Netscape  application  recognizes  the  following  certificate  types:i7 

•  Personal  (or  client)  certificates:  These  certify  the  identity  and 
public  key  of  a  client. 

•  Server  (or  site)  certificates:  These  certify  the  identity  and  public 
key  of  a  server. 

•  Secure  email  certificates:  These  certify  the  identity  and  public  key 
of  an  email  application  user.  It  is  also  used  to  encrypt  and  decrypt 
email  messages. 

•  CA  certificates:  These  certify  the  identity  and  signing  key  of  a 
certificate  authority. 

F.  CERTIFICATE  FORMAT 

Currently,  several  certificate  formats  are  available,  but  the  most  widely  adopted 
meet  the  X.509  specification  lauded  by  the  International  Telecommunication  Union 
(ITU-T)  and  developed  in  1988.  “The  X.509  certificate  format  has  evolved  through  three 
versions  -  the  1988  version  (vl),  the  1993  version  (v2),  and  a  new  version  (v3)  allows  for 


17  Netscape  Communications  Corporation,  “Understanding  Certificates,” 
[http://developer.netscape.com/docs/manuals/certificate/certagnt/overview.htm1.  1997.  Accessed  June 


2004 


14 


many  certificate  extension  fields  required  for  PKI,  and  it  is  reeommended  that  PKI 
planning  assume  use  of  v3.”i8  Regardless  of  the  eertifieate  version  chosen,  most  have 
similar  eontent.  Every  X.509  eertifieate  consists  of:i9 

•  A  data  section  which  includes  the  following  information; 

o  The  version  number  of  the  X.509  standard  supported  by  the 
eertifieate. 

o  The  eertifieate’s  serial  number.  Every  eertifieate  issued  by 
a  CA  has  a  unique  serial  number. 

•  An  information  seetion  whieh  includes  the  following  information: 

o  Information  about  the  user’s  publie  key,  ineluding  the 
algorithm  used  and  a  representation  of  the  key  itself 

o  The  DN  of  the  CA  that  issued  the  eertifieate. 

o  The  period  during  which  the  eertifieate  is  valid. 

o  The  DN  of  the  eertifieate  subject  also  called  the  subjeet 
name. 

o  Optional  eertifieate  extensions,  which  may  provide 
additional  data  used  by  the  client  or  server. 

•  A  signature  section  which  includes  the  following  information: 

o  The  eryptographie  algorithm,  or  cipher,  used  by  the  issuing 
CA  to  ereate  its  own  digital  signature. 

o  The  CA’s  digital  signature,  obtained  by  hashing  all  the  data 
in  the  eertifieate  together  and  enerypting  it  with  the  CA's 
private  key. 


G.  SUMMARY 

In  this  ehapter  we  reviewed  the  core  of  public  key  eryptography,  whieh  eonsists 
of  using  two  mathematically  related  keys  to  encode  and  deeode  messages.  The  key  pair 
ineludes  one  public  key  that  is  widely  distributed  and  a  private  key.  PKI  provides  the  user 

18  Warwick  Ford,  “A  Public  Key  Infrastructure  for  U.S.  Government  Unclassified  but  Sensitive 
Applications,”  September  1,  1995. 

19  Netscape  Communications  Corporation,  “Administrator’s  Guide,  Netscape  Security  Management 
System  Version  6.1,”  [httpi/Zenterp rise. netscape.com/docs/cms/61/cert/pdf/cms61admin.pdfl.  February 
2003.  Accessed  June  2004. 
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with  the  basic  services  of  confidentiality,  integrity,  authenticity  and  non-repudiation.  It 
allows  for  secure  communication  between  subscribers  through  the  concepts  of  digital 
signatures  and  certificates.  A  PKI  can  be  established  in  various  arrangements,  but  the 
baseline  PKI  components  of:  certificate  authority,  end  entity  and  repositories  remain 
unchanged.  An  organization  may  decide  to  include  the  optional  RA  component  to 
enhance  the  scalability  of  the  CA.  The  next  chapter  will  outline  specific  policy  issues  and 
how  the  CISR  lab  compares  to  DoD  specifications  for  PKI  implementation. 
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III.  NPS  CISR  LAB 


A.  DESCRIPTION 

Information  security  is  a  relevant  aspect  of  DoD  operations,  and  therefore,  the  use 
of  PKI  is  becoming  a  more  widely  used  practice.  The  Naval  Postgraduate  School’s 
Center  for  Information  Systems  Security  Studies  and  Research’s  (CISR)  mission  is  to 
address  the  Information  Assurance  (I A)  needs  of  the  war  tighter.  NPS,  through  the  CISR 
facility,  has  a  highly  motivated  academic  research  group  focused  on  issues  of  computer 
security,  which  makes  it  well  suited  to  conduct  research  on  PKI. 

A  test  PKI  system  will  enhance  a  student’s  understanding  of  the  PKI  allowing  for 
additional  research  and  special  projects  on  the  PKI  registration  process,  key  escrow  and 
recovery,  lifecycle  of  digital  certificates  and  innovative  ideas  to  improve  PKI  service 
implementation.  In  addition,  a  PKI  in  the  CISR  lab  will  provide  a  method  for  NPS  to 
produce  digital  certificates  during  its  participation  in  cyber  attack/defend  exercises 
conducted  with  other  commands/services/schools/agencies  (C/S/S/A).  Portions  of  the  lab 
equipment  are  connected  to  the  internal  NPS  domain,  with  access  to  the  outside  world  to 
allow  for  research  and  standard  connectivity  capability.  Other  portions  are  restricted  to  a 
private  network  to  facilitate  the  isolation  of  cyber  war  games. 

B,  FACILITY  DEFICIENCIES 

The  test  bed  PKI  is  located  in  the  CISR  lab  on  the  fifth  deck  of  Spanagel  Hall 
room  500.  The  CISR  lab  is  in  use  by  a  multitude  of  students,  professors  and  research 
associates,  and  is  viewed  by  escorted  visitors  several  times  per  quarter.  The  facility  has  a 
cipher  lock  at  each  of  three  entrances  with  differing  combinations.  One  combination 
allows  individual  access  to  Spanagel  Hall’s  500  and  51 1  CISR  lab  facilities. 

The  DoD  Certificate  Policy  (CP)  states,  “CA  equipment  shall  always  be  protected 
from  unauthorized  access. ”20  The  multi  functional  aspects  of  the  CISR  lab  prevent  NPS 
from  meeting  this  requirement.  Students  from  several  classes  each  quarter  have  access  to 
the  lab  at  any  given  time  during  the  day.  Students  working  on  their  theses  and  students 
participating  in  special  projects  or  exercises  also  have  continuous  access  to  the  lab. 

20  Department  of  Defense  Public  Key  Infrastructure  Program  Management  Office,  “X.509  Certificate 
Policy  for  the  United  States  Department  of  Defense,”  December  1 1,  2003,  Version  8. 
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Although  an  unspoken  rule  exists  that  no  one  will  toueh  another’s  equipment  or  projeets 
without  eonsent,  the  CISR  lab  fails  to  meet  the  DoD  CP  requirements  for  physieal  access 
control. 

Policy  also  dictates  that  if  the  lab  is  physically  unattended  for  more  than  24  hours, 
an  intrusion  detection  system  for  physical  access  or  security  check  should  be 
incorporated.  The  security  check  is  intended  to  ensure  that  the  CA  has  not  been  tampered 
with  and  is  in  the  proper  mode  of  operation,  and  that  security  containers  containing  PKI 
related  materials  are  properly  secured,  and  physical  security  systems  are  operational.  The 
security  check  would  provide  an  extra  layer  of  protection  against  unauthorized  access. 
Guidance  further  states  that  a  person  or  groups  of  people  should  be  responsible  for 
conducting  the  security  checks.  The  adoption  of  the  latter  mandates  the  maintenance  of  a 
security  schedule  dictating  the  responsible  individual  with  the  date  and  time  of  this 
inspection. 

For  fire  prevention  and  protection,  the  X.509  rescinded  the  need  for  a  sprinkler 
system  and  fire  extinguishers  to  be  present  in  the  area  housing  the  CA.  The  CISR  lab 
does  not  a  have  a  sprinkler  system  but  it  does  have  a  fire  extinguisher  located  in  the 
adjoining  lab,  as  well  as  manual  fire  alarms  and  a  halon  system.  The  X.509  states  that  a 
descriptive  approach  for  Certificate  Management  Authority  (CMA)  recovery  from  a 
disastrous  fire  should  be  included  in  an  organization’s  Disaster  Recovery  Plan.  Since  the 
CISR  lab  is  a  research  facility,  it  does  not  have  a  bona  fide  Disaster  Recovery  Plan.  In  the 
event  of  a  disaster,  the  system  will  be  “recovered”  as  best  as  possible  by  the  system 
administrator. 

Also,  part  of  the  Disaster  Recovery  Plan  and  a  required  mechanism  for  physical 
security,  is  the  need  for  a  redundant  CA  power  source  to  allow  for  completion  of  any 
pending  actions  prior  to  a  complete  loss  of  power.  The  CISR  facility  does  not  have  an 
uninterruptible  power  supply  (UPS)  associated  with  the  PKI  prototype.  The  Disaster 
Recovery  Plan  also  includes  the  need  for  an  offsite  backup  facility  with  periodic  backups 
conducted  on  a  weekly  basis  for  continuously  operated  Class  3  CAs.21  The  PKI  will 
provide  functionality  during  cyber  defense  exercises  and  facilitate  follow  on  research  in 

21  Ibid. 
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PKI  issues.  It  will  not  be  used  outside  of  NPS  for  real-world  operations.  Beeause  the 
CMS  is  reserved  for  research  purposes  only  and  poses  no  threat  to  the  CISR 
organization’s  network  security  or  daily  operations,  the  requirement  to  invest  in  a  backup 
facility  to  protect  the  CMS  data  is  not  deemed  essential.  This  thesis  contains  an 
installation  guide  that  enables  the  PKI  to  be  recreated  in  the  event  of  total  loss. 

C.  ADJUSTMENTS  FOR  FULL  COMPLIANCE 

1.  Physical  Access 

Physical  Security  Adjustments  that  need  to  occur  in  the  NPS  CISR  facility  to 
make  the  PKI  system  DoD  compliant  would  require  additional  funding,  space  and/or 
policy  changes.  All  equipment  designated  for  the  PKI  is  required  to  be  in  a  controlled 
environment.  The  CISR  lab  would  have  to  designate  a  space  for  the  CA  in  its  current  lab 
and  restrict  unauthorized  access  or  acquire  a  new  facility  to  house  the  CA.  If  a  new 
facility  is  desired,  DITSCAP,  (DoD  Information  Technology  Security  Certification 
Accreditation  Process),  the  certifying  agent  for  all  DoD  IS,  would  have  to  approve  the 
facility  for  accreditation  to  support  a  CA.22  The  facility  would  need  its  own  air 
conditioning,  power  source,  fire  protection  system  and  carbon  dioxide  detectors. 
Equipment  would  have  to  be  protected  from  flooding  by  utilizing  raised  floors.  An 
intrusion  detection  system  would  need  to  be  employed  due  to  the  absence  of  personnel 
for  periods  greater  than  24  hours.  An  off-site  backup  facility  would  have  to  be  selected  to 
store  data  in  the  case  of  a  disaster  wherein  data  is  destroyed. 

2.  Procedural  Controls 

The  DoD  prepared  a  Certification  Practice  Statement  (CPS)  that,  “Establishes  the 
procedures  which  satisfy  the  Certificate  Policy  for  the  management  of  certificates  within 
a  Certificate  Authority  domain  and  states  the  operating  procedures  for  the  Certification 
Authority,  clarifying  the  legal  rights  and  obligations. ”23  Because  certificates  are  legally 
binding  and  can  be  upheld  in  a  court  of  law,  certain  procedures  must  be  instituted  to 
ensure  the  integrity  of  the  CA.  The  CPS  has  adopted  specific  policies  to  protect  the  DoD 
PKI  architecture.  The  CPS  states, 

22  United  States  Department  of  Defense,  “Defense  Information  Infrastructure  Certification  Authority 
Certification  Practices  Statement  for  Release  3,  Version  4.1,  May  15,  2002. 

23  Space  and  Naval  Warfare  Systems  Command  Information  Systems  Security  Information  Warfare 
Defense  Program  Management  Office,  “Department  of  Defense  Public  Key  Infrastructure  Primer,  Version 
3.0,”  June  18,  2001. 


19 


The  trusted  roles  must  be  filled  by  a  least  two  different  individuals  at  a 
CA.  Sinee  all  of  these  roles  require  UNIX  “root”  privileges,  proeedural 
two-person  eontrol  will  be  used  to  aeeess  the  CA  system.24 

This  thesis  was  originally  envisioned  to  adhere  to  the  DoD  standard  for  PKI 
implementation.  The  DoD  defines  two-person  eontrol  as  “the  eontinuous  surveillance  and 
control  of  positive  control  material  at  all  times  by  a  minimum  of  two  authorized 
individuals,  each  capable  of  detecting  incorrect  or  unauthorized  procedures  with  respect 
to  the  task  being  performed  and  each  familiar  with  established  security  requirements. ”25 
In  the  CISR  lab,  an  entire  class  may  have  complete  access  to  the  PKI,  allowing  them  to 
make  changes  without  visibility  to  other  trusted  agents.  This  security  flaw  will  not  be 
addressed  since  the  CISR  PKI  will  be  used  to  create  test  certificates  and  will  not  be  used 
in  an  official  high  assurance  capacity. 

The  CPS  further  recommends  the  separation  and  appointment  of  individuals  for 
the  role  of  Certification  Authority,  Registration  Authority,  Local  Registration  Authority, 
Server  Administrator,  Code  Signing  Attribute  Authority,  System  Administrator,  ISSO, 
Crypto-Officer  and  Operator.  The  CPS  guidance  reads. 

The  system  administrator  and  crypto  officer  roles  should  never  be 
combined.  The  ISSO  role  must  be  assigned  to  some  one  who  does  not 
have  the  operator  role  or  the  crypto  officer  role. 

The  CPS  provides  guidelines  that  may  be  tailored  to  an  organization’s  needs. 
Therefore,  the  NPS  CA  does  not  have  a  delineation  of  such  roles  due  to  the  use  of  the  CA 
for  research  purposes,  and  whereby,  one  or  more  thesis  students  could  perform  any  or  all 
roles. 


3,  Personnel  Controls 

The  X.509  dictates. 

Persons  shall  be  selected  for  any  CMA  or  other  trusted  role  on  the  basis  of 
loyalty  to  the  United  States,  their  trustworthiness,  and  integrity.  CMAs 
may  be  US  uniformed  service  members,  or  government  civilian  employees 
(Federal,  State,  or  local)  of  any  organization  authorized  by  the  PMA  to 
possess  and  issue  DoD  PKI  certificates  in  accordance  with  Section  1.3. 3.1 

24  United  States  Department  of  Defense,  “Defense  Information  Infrastructure  Certification  Authority 
Certificate  Practices  Statement  for  Class  3  Assurance  Version  3.91,”  August  8,  2001. 

25  Joint  Publication  1-02,  “DoD  Dictionary  of  Military  and  Associated  Terms,” 
rhttp://www.dtic.mil/doctrine/iel/doddict/data/t/05537.html1.  March  2004.  Accessed  June  2004. 
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of  this  CP,  or  such  organizations'  contractors.  All  CMAs  shall  be  US 

citizens.  All  persons  filling  trusted  roles  other  than  CMAs  should  be  US 

citizens  or  hold  a  US  security  clearance. 

It  further  states  that  background  checks  should  be  conducted  on  personnel  placed 
in  other  trusted  roles  for  the  PKI.  The  CISR  lab  participants  are  eomprised  of  U.S. 
citizens  and  students  from  approximately  30  other  countries.  The  oecasion  might  arise 
where  the  need  to  have  a  foreign  national  act  in  a  privilege  role  may  oecur.  Since  the  NPS 
CA  is  restricted  to  NIPRNET  aceess  and  only  generates  “test”  certificates  (i.e., 
certificates  whose  signing  CA  are  not  recognized  outside  of  the  NPS  lab  domain)  the 
requirements  for  U.S.  eitizenship,  a  security  clearance  and  baekground  eheck  were  not 
followed. 

4.  Computer  Security  Controls 

“CA  and  OCSP  Responder  equipment  used  for  CLASS  3  assuranee 
infrastructures  shall  use  operating  systems  that: 

•  Require  authenticated  logins 

•  Provide  diseretionary  access  control 

•  Provide  a  seeurity  audit  eapability.”26 

The  workstation  that  houses  the  CA  does  not  have  an  authenticated  login 
eurrently  installed.  However,  this  can  easily  be  implemented  but  is  not  viewed  as  a 
neeessity  since  the  CA  is  being  utilized  for  research  purposes.  The  CPS  dictates  that  the 
workstation  for  the  CA  server  passes  a  DITSCAP  accreditation  process.  The  NPS  CA 
will  not  request  DITSCAP  eertification  due  to  its  primary  usage  being  researeh. 

5.  Network  Security  Controls 

The  DoD  CPS  requires  the  CA  to  be  connected  to  a  single  network  with  the 
servers  proteeted  by  a  firewall  and  equipped  with  a  meehanism  to  prohibit  unauthorized 
physieal  aceess.  Table  3  illustrates  the  DOD  proposed  configuration  of  firewalls.  The 
NPS  CISR  lab  is  in  compliance  with  the  network  seeurity  criteria  with  the  exception  of 
the  physical  access  restrictive  measure.  Following  the  Solaris  security  precautions  that 
daemons  should  not  run  as  root,  the  default  Idap  port  numbers  were  not  used.  Instead, 
ports  38900,  1027,  1037,  and  1035  were  used,  which  are  also  opened  through  the 
firewall. 

26  X.509. 
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(PRIVATE)  Service 

Port 

Protocol 

In 

Out 

HTTP 

80 

TCP 

Y 

Y 

HTTPS 

443 

TCP 

Y 

Y 

LDAP 

389 

TCP 

Y 

Y 

LDAP 

390 

TCP 

Y 

Y 

LDAPS 

636 

TCP 

Y 

Y 

LDAPS 

637 

TCP 

Y 

Y 

DNS 

53 

UDP 

N 

Y 

SMTP 

25 

TCP 

N 

Y 

Table  3.  Recommended  Firewall  Configurations 


D,  SUMMARY 

The  DoD  CPS  and  the  X.509  standards  were  utilized  and  provided  a  roadmap  for 
thesis  students  to  follow  in  creating  the  PKI  prototype.  Due  to  the  CISR  lab  PKI  facility 
deficiencies  and  the  desire  to  create  a  PKI  for  research  purposes,  the  DoD 
recommendations  were  altered  to  meet  the  much  less  stringent  security  requirements  of 
the  NPS  research  environment.  The  following  chapter  will  expound  on  the  selection  of 
equipment  and  software  used  to  create  the  PKI. 
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IV.  SELECTION  OF  EQUIPMENT  AND  SOFTWARE 


A.  HARDWARE 

The  CISR  lab  boasts  a  multitude  of  equipment  and  hardware  components  that  are 
utilized  by  students,  faculty  and  staff  for  research  purposes,  and  lab  exercises  in  support 
of  class  work.  The  equipment  is  also  used  to  compete  against  other  research  institutions 
in  cyber  defense  exercises.  NFS,  having  just  participated  in  a  cyber  defense  competition 
in  which  two  Sun  Blade  lOO’s  were  utilized,  did  not  have  follow-on  work  making  them 
available  for  utilization.  The  DoD  Root  CA  and  the  subsidiary  CAs  currently  run  on  Sun 
boxes  so  the  Sun  Blades  were  optimal  for  a  PKI  installation  in  the  CISR  lab. 

Installation  and  configuration  of  the  PKI  subsystems  revealed  that  the  Sun  boxes 
did  not  have  adequate  memory.  With  each  running  only  256  MB  of  SDRAM,  the 
machines  responded  poorly  during  configuration  changes.  A  memory  upgrade  was 
required  to  support  this  research.  Two  512  MB,  168-pin  DIMM  SDRAM  PCI33 
memory  chips  were  added  to  each  box  increasing  the  RMA  to  greater  than  I  gigabyte. 
This  memory  increase  helped  with  the  processing  speed  of  the  CMS  system  during 
configuration  changes  and  while  all  of  the  services  installed  were  running 
simultaneously.  The  improved  performance  proved  sufficient  to  support  this  project. 

B,  SOFTWARE 

1,  Software  Selection 

The  initial  research  into  the  current  DoD  implementation  and  the  desire  to 
implement  a  DoD  compliant  PKI,  led  to  the  selection  of  the  Netscape  Certificate 
Management  System  (CMS).  DISA,  Defense  Information  Systems  Agency,  entered  a 
license  agreement  for  all  of  DoD  with  the  AOL-Sun-Netscape  alliance  to  offer  their  PKI 
software  for  various  implementations  throughout  DoD.  When  the  license  agreement 
ended,  DISA  renewed  the  license  with  America  Online  Strategic  Business  Solution  (AOL 
SBS).  Netscape  has  created  multiple  version  of  its  CMS,  allowing  it  to  run  on  many 
different  platforms.  Netscape  CMS  was  chosen  for  this  project  because 
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•  It  is  the  current  DoD  standard 

•  Licenses  were  available  under  the  DISA  enterprise  license,  and 

•  There  was  a  version  compatible  with  the  Sun  systems  at  NFS. 

2,  CMS  Components 

The  Netscape  CMS  architecture  works  with  a  GUI  interface,  the  Netscape 
Console,  and  three  different  systems,  the  Administration  Server,  the  Directory  Server, 
and  the  CMS  itself.  Each  server  is  referred  to  as  an  instance  in  the  Netscape  Console  and 
one  instance  of  each  of  the  three  systems  is  installed  in  a  server  group  during  the  initial 
software  installation  (Figure  3). 


Figure  3.  Netscape  CMS  Server  Group  after  Initial  Installation 

•  Netscape  Console  “is  the  front-end  management  application  for  Netscape 
software  in  your  enterprise.  It  finds  all  servers  and  applications  registered 
in  your  configuration  directory,  displays  them  in  a  graphical  interface,  and 
lets  you  manage  and  configure  them.  In  addition,  Netscape  Console 
provides  graphical  tools  for  locating  and  managing  entries  in  the  user 

directory. ”27 

•  Administration  Server  -  controls  the  resources  used  by  the  directory  server 
instance  and  the  CMS  instance.  It  executes  programs  “to  modify  the 
server  and  application  settings  that  are  stored  in  the  configuration 
directory  or  to  change  the  port  number  that  a  server  listens  to. ”28 


27  Netscape  Communications  Corporation,  “Managing  Servers  with  Netscape  Console,” 
rhttp://enterprise. netscape. com/docs/cms/61/admin/ag/l  intro.htm#!  12841.  August  2002.  Accessed  June 
2004. 

28  Ibid. 
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•  Directory  Server  “is  a  robust,  scalable  server  designed  to  manage  an 
enterprise-wide  directory  of  users  and  resources.  It  is  based  on  an  open- 
systems  server  protocol  called  the  Lightweight  Directory  Access  Protocol 
(LDAP).”29 

•  CMS  -  hosts  “a  highly  configurable  set  of  software  components  and  tools 
for  creating,  deploying,  and  managing  certificates. ”30 

3,  CMS  Subsystems 

The  Certificate  Management  System  is  the  core  of  the  PKI.  To  provide  flexibility 
in  a  PKI,  the  CMS  instance  can  be  configured  as  one  of  four  possible  subsystems. 

•  Certificate  Manager  (CA)  serves  as  the  Certificate  Authority  for  the  PKI. 
A  CA  instance  can  be  configured  as  either  a  Root  CA  that  creates  a  self- 
signed  certificate  or  a  subsidiary  CA  that  requests  a  signing  certificate 
from  another  trusted  CA.  The  CA  provides  “functionality  for  issuing, 
renewing,  revoking,  and  publishing  certificates  and  creating  and 
publishing  Certificate  Revocation  Lists  (CRLs).”3i 

•  Registration  Manager  (RA)  is  used  for  user  verification  and  certificate 
request  approval.  Approved  requests  are  then  sent  to  the  CA  for 
certificate  creation  using  a  trusted  certificate  issued  by  the  CA. 

•  Online  Certificate  Status  Manager  (OCSM)  is  used  as  an  Online 
Certificate  Status  Protocol  (OCSP)  service  “for  real-time  verification  of 
certificates  issued  by  the  Certificate  Manager.”32 

•  Data  Recovery  Manager  (DRM  or  KRA)  provides  encrypted  storage  for 

private  keys  and  facilitates  their  recovery. 

4,  Nuts  and  Bolts 

The  CMS  itself  is  a  set  of  “pure  JAVA  classes”33.  Each  subsystem  is  installed 
and  configured  with  HTTP  servlets  to  enable  subsystem  services.  The  default 
installations  of  all  of  the  subsystems  can  be  enhanced  using  configurable  JAVA  plug-ins. 
These  modules  (JAVA  plug-ins)  can  be  used  to  configure  a  variety  of  services  including: 

•  Access  Control  Lists 

•  Authentication 


29  Netscape  Communications  Corporation,  “Administrator’s  Guide  Netscape  Directory  Server,” 
rhttp://enterp rise. netscape. com/docs/directorv/61/ag/intro.htm#l 0438861.  August  2002.  Accessed  June 
2004. 

30  Netscape  Communications  Corporation,  “Administrator’s  Guide  Netscape  Certificate  Management 
System  Version  6.1,”  February  2003.  (Administrator’s  Guide) 

31  Administrator’s  Guide,  p.  30. 

32  Ibid.,  167. 


33  Ibid.,  p.  58. 
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•  Authorization 

•  Logging 

•  Job  schedule 

•  Publishing 

•  Email  notifieation 

•  Event  listeners 

The  diagram  (Eigure  4)  below  is  the  architeeture  of  the  CMS.  The  rest  of  this 
ehapter  will  go  into  more  detail  about  the  speeifics  of  the  CA,  RA,  and  KRA  subsystems 
used  in  the  PKI,  how  they  communicate  with  each  other  and  the  proeesses  used  for  the 
eertifieate  life-eyele. 
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Figure  4.  CMS  Architecture34 

a.  HTTP  and  JA  VA  Servlets 

Though  CMS  is  built  on  the  foundation  of  JAVA  elasses,  other 
programming  languages  and  serviees  are  needed  to  eomplete  the  funetionality.  A  key 
aspeet  of  eommunieation  with  the  subsystems  by  users  and  agents  is  the  HTTP  engine. 
This  serviee  is  provided  by  the  Netseape  Enterprise  Server  that  “delivers  statie  and 
dynamie  Web  eontent”.  Netseape  Enterprise  Server  supports  “most  current  standards 
including  HTTP  1.1,  SSL,  PKCS#11,  and  LDAP”  and  provides  both  content  and 


34  Ibid.,  p.  58. 
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functionality  of  the  non-SSL  and  SSL  end-entity  web  interfaees  and  the  agent’s  SSL  web 
interface.  While  these  interfaees  will  be  deseribed  in  depth  in  the  Functionality  section  of 
this  chapter,  the  HTML  pages  are  enhaneed,  their  eontent  ereated,  and  requests  proeessed 
by  the  JAVA  servlets.  Each  subsystem  has  specific  servlets  for  their  purposes.  The 
OCSM  and  the  CA’s  OCSP  responder  use  JAVA  servlets  to  respond  to  OCSP  requests. 

b.  NSS 

“Network  Seeurity  Serviees  (NSS)  is  a  set  of  libraries  designed  to  support 
eross-platform  development  of  seeurity-enabled  communieations  applioations.”35  NSS 
helps  make  the  SSL  elient  authentieation  and  other  secure  communieations  between 
subsystems  work. 

c.  JSS  and  the  JA  VA/JNI  Layer 

The  Java  Security  Services  (JSS)  is  the  Java  foundation  for  the  Java 
interfaee  with  NSS.  Built  using  the  Java  Native  Interfaee  (JNI),  JSS  allows  for 
eustomizable  serviees  to  be  created  for  the  subsystems.  These  services  ean  then  be 
successfully  run  by  different  versions  of  the  Java  Virtual  Machine  (JVM). 36 

d.  PKCS  #11 

One  of  the  keys  to  a  sueeessful  PKI  is  strong  cryptographie  information. 
For  this,  the  CMS  uses  Public -Key  Cryptography  Standard  #11  modules  which 
communicate  with  eryptographic  storage  deviees.  “The  PKCS  standards  are 

speeifications  that  were  developed  by  RSA  Seeurity  in  eonjunetion  with  system 
developers  worldwide  (sueh  as  Mierosoft,  Apple,  Sun  etc.)  for  the  purpose  of 
aeeelerating  the  deployment  of  public  key  eryptography.”  37 

The  CISR  PKI  uses  the  Internal  Crypto  Serviees  token  used  by  each 
subsystem  to  perform  eryptographic  operations.  Another  benefit  of  CMS  is  that  it  also 
eomes  with  the  FIPS  (Federal  Information  Proteetion  Standard)  I40-I  eompliant  module. 


35  Ibid.,  p.  62. 

36  Ibid.,  p.  61. 

37  Mohan  Atreya,  “Introduction  to  PKCS  Standards,” 

[http://www.rsasecuritv.cotn/products/bsafe/overview/IntroToPKCSstandards.pdf#xmLhttp://www.rsasecu 

ritv.com/programs/texis. exe/webinator/searcli/xml.txt?querv=pkcs+%231Q&pr=default  new&order=r&cq= 

&id=4Qc6el3bb1.  2004.  Accessed  June  2004. 
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FIPS  140-1  is  an  “evaluation  criteria  associated  with  cryptographic  modules. ”38  The 
default  model  of  the  CMS  is  not  DoD  compliant,  further  research  should  be  done  using 
FIPS  140-1  to  ensure  compliance  with  DoD  standards. 

e.  Command  Line  Tools 

For  those  users  more  comfortable  with  command  line  operations  and  to 
allow  for  greater  customization,  Netscape  has  provided  a  variety  of  command  line  tools 
for  CMS  management.  They  include  certutil,  a  backup/restore  tool,  a  password  cache 
tool  and  a  mass  revocation  tool  to  name  a  few.  Certutil,  or  the  Certificate  Database  Tool, 
“is  a  command-line  utility  that  can  create  and  modify  the  Netscape  Communicator 
certV.db  and  keyS.db  database  files. ”39  For  CMS,  these  files  are  maintained  in  the 
internal  token  and  are  used  to  validate  certificates  the  CMS  receives.40  The  CMS 
Software  Development  Kit  (SDK)  can  also  be  used  for  customization  and  tutorials  for  use 
with  command  line  tools  and  other  functions  of  the  CMS. 

C.  INSTALLATION  ISSUES 

During  the  conduct  of  this  research,  several  issues  arose  during  the  installation  of 
the  CMS  software  on  the  NPS  Sun  machines.  CMS  6.1  currently  has  two  versions  one 
for  Solaris  8  and  one  for  Windows  NT.  The  selection  of  the  Sun  Blade  100s  dictated  that 
the  version  for  Solaris  8  was  used.  Unfortunately,  the  Sun  boxes  had  been  previously 
configured  with  hardened  security  features  for  the  Cyber  Defense  exercise  and  were 
running  Solaris  9.  These  security  features  caused  the  initial  installation  attempts  to  fail 
miserably.  The  solution  was  to  reformat  both  boxes  and  begin  with  fresh  installation  of 
Solaris  8.  Once  a  successful  installation  was  completed,  the  decisions  turned  to  the 
deployment  scheme  of  the  PKI. 

The  second  issue  was  the  limitation  of  the  hardware.  Figure  5  is  the  preferred 
deployment  scheme  of  a  PKI,  one  host  for  each  of  the  three  subsystems,  a  Certificate 
Manager,  Registration  Manager,  and  Data  Recovery  Manager. 


38  Carlisle  Adams  and  Steve  Lloyd,  “Understanding  PKI,  2"‘*  Edition,”  Addison  Wesley,  2003. 

39  The  Mozilla  Organization,  “Using  the  Certificate  Database  Tool,” 

lhttt)://www.mozilla.org/proiects/securitv/pki/nss/tools/certutil.htnil1.  December  2002.  Accessed  June 
2004. 

40  Administrator’s  Guide,  p.  294. 
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Pu  bli  shing  directory 


Recovery 

Manager 

Figure  5.  Certificate  Manager,  Registration  Manager  and  Data  Recovery  Manager  in 

Separate  Instances  4i 


Unfortunately  with  only  two  machines  available  in  the  NFS  CISR  lab  to  support  this 
project,  an  alternate  (non-op timal)  solution  was  adopted. 

As  discussed  above,  the  CMS  software  contains  an  administration  server,  a 
directory  server  and  a  CMS  server.  Each  server  is  referred  to  as  an  instance  in  the 
Netscape  Console  which  is  a  graphical  user  interface  (GUI)  used  to  configure  and  control 
the  Netscape  servers.  One  instance  of  each  of  the  three  servers  is  installed  in  a  server 
group  during  the  initial  setup.  Netscape  allows  for  two  configurations  if  multiple  CMS 
instances  are  required  on  one  machine.  First,  one  server  group  can  be  installed  and  then 


41  Ibid. 
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multiple  CMS  instances  can  be  added  to  the  group.  Second,  multiple  server  groups  can 
be  installed  each  with  their  own  set  of  three  servers.  The  deployment  scheme  chosen  for 
the  CISR  PKI  included  a  root  CA,  a  RA  and  a  KRA  or  Data  Recovery  Manager  (DRM  is 
used  by  Netscape  to  refer  to  a  KRA).  With  only  two  computers,  the  decision  was  made 
to  place  the  CA  and  KRA  on  one  machine  and  the  RA  on  the  other.  The  CA  was  setup 
first  in  the  server  group  and  then  a  second  CMS  instance  was  created  and  setup  as  the 
KRA  as  shown  in  Figure  6.  The  problem  arose  when  trying  to  start  the  KRA  instance. 


Figure  6.  One  Server  Group  with  Two  CMS  Instances. 

Only  one  CMS  instance  would  run  at  one  time  in  the  server  group.  This 
deployment  scheme  was  scrapped  and  a  second  deployment  option  for  multiple  server 
groups  was  used  for  the  future  installations  (Figure  7).  Multiple  server  groups  allowed 
both  CMS  instances  to  function  concurrently  with  no  failures  to  start  the  KRA  instance. 
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Figure  7.  Multiple  Server  Groups 

The  initial  projeet  envisioned  an  OCSM  instance  to  provide  OCSP  services. 
When  attempting  to  add  an  OCSM  to  the  above  deployment  scheme,  another  issue 
developed.  The  not  enough  disk  space  error  was  received.  The  routine  solution  to  this 
problem  is  to  reformat  the  hard  drive,  reinstall  the  operating  system  and  repartition  the 
disk  space  to  accommodate  the  software.  Not  wanting  to  remove  all  of  the  work 
successfully  completed,  another  alternative  was  tried.  A  second  hard  drive  was  installed 
in  the  computer  and  the  essential  partitions  were  copied  to  it  once  they  were  checked  for 
errors.  Once  this  was  completed,  the  format  command  was  used  to  repartition  the  first 
hard  drive,  increasing  the  root  partition  to  5  Gigabytes.  With  repartitioning  complete,  the 
data  saved  on  the  second  hard  drive  was  then  dumped  back  to  the  first  hard  drive.  These 
steps  were  then  repeated  for  the  second  machine.  Once  the  repartitioning  was 
accomplished,  no  future  issues  occurred  because  of  disk  space. 

D.  FUNCTIONAL  OVERVIEW 

The  CMS  operates  using  a  combination  of  many  different  languages  and  types  of 
files.  This  section  will  discuss  some  of  the  specific  files  and  interfaces  used  for  the 
operation  and  configuration  of  the  CMS  PKI.  The  majority  of  the  configuration 
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information  used  by  the  Administration  Server  are  loeated  in  the  eonfig  directory  of  the 
CMS  instance.  This  information  is  what  is  seen  through  the  Administrative  Interface  and 
used  to  perform  the  tasks  of  the  subsystem. 

1.  Interfaces 

There  are  four  interfaces  that  allow  users  to  communicate  with  a  CMS  subsystem, 
the  Non-SSL  and  SSL  end-entity  interfaces,  the  agent  interface,  and  the  administration 
interface  also  called  the  Netscape  Console. 

a.  Administrative  Interface 

Each  subsystem  is  managed  through  the  Netscape  Console  and 
Administration  Server,  also  known  as  the  Administrative  Interface.  “Based  on  the 
information  given  at  each  command,  the  administration  servlets  allow  administrators  to 
perform  administrative  tasks  and  configure  plug-in  modules  and  instances  of  plug-in 
modules. ”42  The  interface  is  similar  for  all  of  the  subsystems,  but  provides  different 
functionality  for  each.  For  instance,  the  DRM  has  a  section  for  changing  recovery  agent 
information  that  the  other  subsystems  do  not  have. 

Although  the  Administrative  Interface  is  only  accessed  through  Netscape 
Console  (Figure  8),  there  are  a  few  HTML  pages  and  templates  that  are  used  for  the 
initial  agent  enrollment.  The  adminEnroll.html  page  allows  the  CA  agent  to  create  a 
request  for  a  certificate  and  the  EnrollSuccess. template  and  ImportCert.template  display 
the  newly  created  certificate  and  allow  for  it  to  be  imported  into  the  browser.  This 
certificate  is  also  added  to  the  user  that  was  created  as  an  administrator  during  the 
configuration  of  the  CMS  instance.  The  Initial  Agent  Enrollment  is  only  available  on  the 
CA  because  there  are  agents  to  approve  requests.  Once  the  agent  is  created,  other 
subsystem  agents  can  go  to  the  CA  with  their  certificate  requests.  These  HTMF  files  are 
located  in  the  agent  subdirectory  of  the  web-apps  directory  of  the  CMS  instance  and  are 
disabled  after  the  initial  agent  has  been  enrolled. 


42  Ibid. 
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Figure  8.  A  View  from  the  Netseape  Console  that  Controls  the  CA. 

b.  Agent  Interface 

The  Agent  Interface  is  used  by  agents  of  the  subsystem  to  perform  specific 
tasks  relating  to  that  subsystem.  For  the  CA  and  RA,  these  activities  consist  of  the 
following;  approving/disapproving  certificate  profiles,  approving  certificate  requests  and 
certificate  renewals.  The  CA  is  the  only  subsystem  that  has  the  controls  for  CRL  creation 
and  issuance.  The  DRM’s  agent  interface  is  used  specifically  for  approving  key  recovery 
requests  and  locating  keys.  For  the  OCSM,  the  interface  is  used  to  control  responses  to 
OCSP  requests  and  CRL  retrieval  and  storage. 

The  agent  interface  is  created  using  a  combination  of  FITML  files  and 
templates  that  use  JavaScript  functions  to  populate  the  information  that  appears  in  the 
web  browser.  These  files  are  maintained  in  the  agent  directory  of  the  web-apps  directory 
in  the  CMS  instance  directory.  The  agent  directory  contains  subdirectories  for  each 
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possible  subsystem  although  only  the  files  relevant  to  the  partieular  instance  are  used. 
They  can  be  modified  to  display  only  that  information  necessary  for  a  particular  PKI 
deployment. 

c.  Non-SSL  and  SSL  Interface 

The  end-entity  interface  allows  for  end-user  communication  with  the  CA, 
RA,  and  OCSM.  The  end-entity  page  can  be  accessed  either  by  http  or  securely  on  https 
using  SSL.  A  certificate  is  used  to  authenticate  the  user  to  the  SSL  for  secure 
communications.  For  the  CA  and  RA,  the  interface  includes: 

•  an  enrollment  tab  with  access  to  certificate  profile  forms 

•  a  revocation  tab  for  user  revocation,  and 

•  a  retrieval  tab  where  users  can  download  their  certificates  and  import  the 

CA  chain. 

The  CA  has  added  functionality  in  that  users  can  list  certificates  and  download  the 
current  CRL.  The  end-entity  interface  of  the  OCSM  is  for  acceptance  and  processing  of 
OCSP  requests  via  JAVA  servlets.  The  DRM  does  not  have  any  end-entity  interfaces. 

Both  the  Non-SSL  and  SSL  end-entity  interfaces  are  also  created  using  a 
combination  of  HTML  files  and  templates  (Figure  9).  The  JavaScript  functions  provide 
information  and  allows  for  authentication  and  access  to  the  SSL  end-entity  interface.  The 
HTML  files  for  the  certificate  enrollment  profiles  are  also  stored  here.  The  options  that 
appear  in  the  key  generation  request  type  and  request  fields  are  determined  based  on  the 
JavaScript  functions  in  the  ProfileSelect.template  and  the  owner’s  web  browser.  These 
files  can  also  be  modified  to  permit  access  to  only  required  areas  or  to  increase 
functionality.  For  example  adding  a  renewal  tab  to  the  screen  that  provided  access  to  the 
certificate  renewal  pages  would  facilitate  owner  certificate  renewal.  The  files  used  for 
these  interfaces  can  be  found  in  the  ee  directory  of  the  web-apps  under  the  subdirectory 
associated  with  the  subsystem. 
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Figure  9.  Screen  Shot  of  the  SSL  End-Entity  Interface  of  the  RA. 

2,  Users  and  Groups 

Access  to  the  administration  and  agent  interfaces  are  controlled  by  registered 
users  and  their  associated  groups.  By  default,  the  Administrators,  Agents,  Auditors,  and 
Trusted  Managers  groups  are  created  for  the  CA.  As  their  names  describe  them, 
members  of  the  Administrators  and  Agents  groups  have  full  access  to  those  interfaces 
respectively.  Auditors  have  access  to  view  signed  audit  logs  only.  Trusted  Managers  is 
the  group  that  holds  information  about  other  subsystems  that  are  registered  as  users  of  the 
CA  such  as  the  Registration  Manager  or  a  subsidiary  CA.  When  a  Trusted  Manager  is 
added  as  a  user,  the  fully  qualified  domain  name  must  be  used  as  the  full  name  of  the  user 
to  allow  recognition  by  the  subsystem.  Users  can  be  assigned  to  one  or  more  of  these 
groups  as  required.  In  order  to  authenticate  securely  each  user  must  have  a  certificate 
associated  with  it.  More  will  be  discussed  about  Trusted  Managers  in  the  Connecting  the 
Subsystems  section.  Eigure  10  shows  the  window  used  to  import  such  a  certificate. 
Users  and  Groups  can  be  added,  modified,  or  deleted  via  the  Users  and  Groups  tabs  that 
appear  when  Users  and  Groups  are  selected  in  the  left-hand  portion  of  the  Netscape 
Console. 
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Figure  10.  Certificates  Associated  with  a  Specific  User 

User  and  Group  information  is  stored  in  the  Directory  Server  instance  created  during  the 
configuration  of  the  CMS  subsystem. 

3,  Connecting  the  Subsystems 

In  order  for  the  PKI  to  work  correctly  there  must  be  a  trust  relationship  between 
the  subsystems.  The  Netscape  CMS  uses  connectors,  the  Trusted  Managers  group,  and 
certificates  to  establish  these  trusted  relationships.  Via  the  console,  the  CA  has  the  ability 
to  connect  to  a  DRM  or  an  OCSM.  The  RA  has  the  ability  to  connect  to  a  DRM  and  a 
CA.  The  connector  must  be  enabled  and  requires  the  host  name,  port  number,  and  a 
timeout  limit.  The  subsystem  must  be  a  user  assigned  to  the  Trusted  Managers  Group  of 
the  subsystem  to  which  it  is  trying  to  connect.  For  example,  for  communication  between 
a  RA  and  CA  to  succeed,  the  RA  must  be  a  user  in  the  CA’s  Trusted  Managers  Group. 
On  the  DRM,  the  CA  user  must  have  the  CA  SSL  certificate  associated  with  it.  The  RA 
must  have  its  signing  certificate  associated.  On  the  CA,  the  RA  user  must  have  a 
matching  signing  certificate  associated  with  that  user.  Below  is  a  snapshot  of  the 
information  for  a  connector  in  the  console  (Figure  1 1). 
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Figure  1 1 .  Information  Associated  with  a  Subsystem  Connector. 


The  next  aspect  of  connecting  the  DRM  with  the  CA  and  RA  involves  imbedding 

the  DRM  transport  certificate  into  a  JavaScript  function  in  the  ProfileSelect.template  used 

to  create  the  html  pages  used  for  certificate  enrollment  profiles  via  the  end-entity 

interfaces.  Below  are  the  functions  used  to  generate  and  send  the  Certificate  Request 

Message  Format  (CRMF)  to  the  KRA.  For  simplicity,  the  majority  of  the  64-base 

encoding  for  the  keyTransportCert  of  the  KRA  has  been  deleted. 

function  validate() 

{ if  (keygen_request  ==  'false') 
return  false; 

with  (document.forms[0])  { 

var  keyTransportCert  =  "MIIDlzCCAn-i-gAwIBAgIBOBwO="; 

//  generate  keys  for  nsm. 
if  (typeof(crypto. version)  !=  "undefined") 

{ if  (dual  ==  'true')  { 

crmfObject  =  crypto.  generateCRMFRequest( 

"CN=x", 

"regToken",  "authenticator",  keyTransportCert, 

"  setCRMFRequestO ; " , 

1024,  null,  "rsa-ex", 

1024,  null,  "rsa-sign"); 

}  else 

{  crmfObject  =  crypto. generateCRMFRequest( 

"CN=x",  "regToken",  "authenticator". 
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keyTransportCert,  "setCRMFRequest();", 

1024,  null,  "rsa-dual-use"); 

} 

}  return  false; 

} 

} 

funetion  setCRMFRequest() 

{ with  (doeument.forms[0]) 

{  eert  request. value  =  ermfObjeet. request;  submit(); 

} 

} 

The  web  browser  that  is  used  by  the  owner  during  the  certificate  request  phase  must 
support  the  creation  of  dual  key  pairs,  one  private  and  one  public.  Netscape  7.1  is 
currently  the  only  browser  that  allows  this  to  be  done  via  a  CRMF  request.  Microsoft’s 
Internet  Explorer  uses  an  internal  cryptographic  provider  for  the  key  generation  and 
storage,  although  a  CRMF  request  should  still  travel  to  the  KRA. 

The  final  step  is  ensuring  the  DRM  trusted  the  certificate  chain  of  the  CA.  This  is 
done  from  the  Netscape  Console  for  the  DRM  under  the  encryption  tab.  The  Manage 
Certificate  button  brings  up  a  list  of  CA  certificates,  their  expiration  date  and  their  trust 
status.  First  the  CA  certificate  must  be  in  this  list  and  second  the  certificate  must  be 
trusted.  This  information  is  maintained  in  the  Directory  Server  installed  during  the 
configuration  of  the  DRM  subsystem.  Figure  12  shows  the  trust  relationship  as  seen  in 
the  Manage  Certificate  window  of  the  RA.  The  CA  trust  relationship  must  also  be  setup 
in  the  RA. 
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Certificate  Database  Management 


Certificates 


Certificate  Name 

Expiry  Date 

T  rust  Status 

Builtin  Object  T oken;Veri... 

July  16,  2036  16:59:59 

Untrusted 

Builtin  Object  T oken;Veri... 

August  01,202816:59:59 

Untrusted 

Builtin  Object  T okeniVeri... 

August  01,202816:59:59 

Untrusted 

Builtin  Object  T oken:Veri... 

July  16,  2036  16:59:59 

Untrusted 

Builtin  Object  T oken:Veri... 

August  01,202816:59:59 

Untrusted 

Builtin  Object  T oken:Veri... 

August  01,202816:59:59 

Untrusted 

Builtin  Object  T oken:Veri... 

July  16,  2036  16:59:59 

Untrusted 

Builtin  Object  T oken:Veri... 

August  01,202816:59:59 

Untrusted 

Builtin  Object  T oken:Veri... 

July  16,  2036  16:59:59 

Untrusted 

Builtin  Object  T oken:Vls... 

August  15, 2020  16:59:00 

Untrusted 

Builtin  Object  Token: Ms... 

August  15, 2020  16:59:00 
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Figure  12.  Manage  Certificates  Window 


At  the  time  of  writing,  there  is  still  an  error  in  the  trust  relationship  between  both 
the  RA  and  CA,  and  the  DRM.  There  is  a  creation  of  a  CRMF  request  during  the 
certificate  enrollment  process,  however  there  is  no  sign  of  it  after  the  request  has  been 
sent  to  the  CA.  One  possible  solution  would  be  to  request  new  certificates  for  the  RA 
and  DRM  using  the  Certificate  Setup  Wizard  that  directly  imports  the  certificates  into 
their  locations  in  the  Directory  Server.  Perhaps  there  was  an  error  in  the  generation  of 
keys  during  the  CMS  configurations  that  prevented  proper  functionality. 

4,  Certificates 

Creating  and  distributing  certificates  are  core  functions  of  a  PKI.  Certificate 
enrollment  can  be  initiated  from  several  different  locations,  the  Non-SSL  and  SSL  end- 
entity  interfaces  and  the  Certificate  Setup  Wizard  in  the  Administrative  Interface  of  a 
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subsystem.  This  section  will  discuss  all  the  various  processes  involved  throughout  a  user 
certificate’s  life-cycle.  Subsystem  certificates  are  created  using  the  Certificate  Setup 
Wizard  and  request  approval  via  the  agent  interface  of  the  CA.  This  wizard  is  accessed 
via  the  Netscape  Console  of  the  subsystem  and  is  discussed  in  detail  in  the  Appendix. 

a.  Certificate  Enrollment 

•  The  owner  opens  a  browser  window  to  one  of  the  end-entity  pages  of  the 
RA. 

•  The  owner  selects  the  Certificate  Profile  he  wishes  to  use,  enters  the 
information  requested,  and  clicks  submit. 

•  The  web  browser  then  generates  the  dual  (public  and  private)  key  pair.  In 
Microsoft  Internet  Explorer  the  keys  are  stored  in  one  of  the 
Cryptographic  Providers.  In  Netscape,  the  keys  are  stored  in  the  Software 
Security  Device. 

•  Internet  Explore  generates  a  PKCS  #10,  a  type  of  message  format 
for  certificate  requests  from  RSA  Securities,  and  sends  the  request 
to  the  RA. 

•  Netscape  generates  a  CRME,  a  type  of  message  format  used  to 
convey  certificate  requests  proposed  by  the  Internet  Engineering 
Task  Eorce  (lETE)  PKIX  working  group,  and  sends  the  request  to 
the  RA. 

•  The  request  is  evaluated  against  existing  profiles  and  accepted  or  rejected. 

•  A  RA  agent  using  the  agent  interface  views  the  certificate  request,  makes 
any  change  necessary,  and  the  approves  or  disapproves  the  request. 

•  Once  approved,  the  RA  signing  certificate  is  used  to  sign  the  request  and 
the  RA  agent  then  forwards  it  to  the  CA. 

•  The  CA  compares  the  request  against  its  own  profiles  and  if  nothing  is 
violated,  it  generates  the  certificate. 

•  If  key  archival  is  requested,  the  certificate  and  the  key  pair  are  transported 
to  the  DRM,  and  signed  by  the  DRM’s  transport  certificate. 

•  An  email  is  then  sent  by  the  CA  to  the  certificate  owner  containing  a  link 
to  the  retrieval  page. 

•  The  owner  then  imports  the  certificate  into  his  browser  and  is  ready  to  go. 
Certificate  requests  and  certificates  are  stored  in  the  Directory  Server 

instance  created  during  the  subsystem  installation.  The  CA  can  also  publish  certificates 
to  this  directory  to  enable  Idap  retrieval  of  the  certificates. 
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b.  Certificate  Renewal 

•  The  Job  Scheduler  of  the  CA  processes  the  Certificate  Renewal 
Notification  Job,  discussed  later  in  this  chapter,  and  sends  an  email  to  the 
certificate  owner. 

•  The  certificate  owner  follows  the  link  in  the  email  to  the  SSL  end-entity 
page  of  the  RA  and  the  Renewal  Page. 

•  At  the  Renewal  Page  the  owner  click  Submit  (Figure  13). 


Figure  13.  Certificate  Renewal  Page 

•  A  selection  window  then  appears  with  a  list  of  certificates  available.  The 
owner  selects  the  certificate  she  wishes  to  renew  and  clicks  ok. 

•  The  request  is  sent  to  the  RA,  which  signs  the  request  and  forwards  it  to 
the  CA. 

•  The  CA  evaluates  the  request  against  its  profiles  and  issues  the  certificate 
if  all  is  in  compliance  with  policy. 

•  The  certificate  is  then  imported  into  the  owner’s  browser, 
c.  Owner  Certificate  Revocation 

•  The  certificate  owner  clicks  on  the  Revocation  tab  of  the  RA’s  SSL  end- 
entity  page  (Figure  14). 
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After  you  click  the  submit  button,  a  window  will  pop  up  with  a  list  of  certificates  you  can  send  to  the  server,  Select  the 
certificate  you  want  to  revoke  from  this  window. 

Important:  This  is  an  irreversible  operation,  If  you  still  want  to  continue,  be  sure  to  request  revocation  on  the  computer 
where  the  private  key  and  certificate  to  be  revoked  are  stored. 


Revocation  Reason 
Select  a  revocation  reason 

®  Unspecified 
O  Key  Compromise 
O  Cessation  of  Operation 
O  Affiiiation  Changed 
O  Superseded 

I  Submit  I  [  Reset  | 


i 

Figure  14.  SSL  End-Entity  page  for  Certifieate  Revocation. 

•  The  owner  selects  the  revocation  reason  and  clicks  Submit. 

•  The  browser  prompts  her  to  select  the  certificate  she  wishes  to  revoke. 

•  The  Certificate  Revocation  Confirmation  page  appears,  with  the  details  of 
the  certificate  chosen  and  the  opportunity  to  add  comments. 

•  Since  the  RA  is  does  not  have  the  authority  to  revoke  certificates,  the 
request  is  forwarded  to  the  CA. 

•  The  certificate  is  revoked  by  the  CA  by  marking  as  such  in  the  database 
(Directory  Server),  the  CRL  is  updated  with  this  new  revocation,  and  it  is 
published  to  the  Directory  Server.  An  email  is  also  sent  to  the  owner 
confirming  that  the  certificate  has  been  revoked. 

d.  Agent  Revocation 

Agent  Revocation  is  similar  to  owner  revocation,  but  it  can  only  be 
performed  through  the  agent  interface  of  the  CA.  The  RA  does  not  have  the  authority  to 
revoke  certificates  as  mentioned  above. 

•  An  agent  of  the  CA  opens  the  agent  interface  of  the  CA. 

•  There  are  two  possible  ways  to  revoke  a  certificate  from  here. 
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•  Select  List  Certificates  and  navigate  to  the  certificate  you  wish  to 
revoke. 

•  Batches  of  certificates  can  be  revoked  by  entering  qualified 
parameters,  such  as  validity  dates  or  all  certificates  approved  by  a 
specific  person,  via  the  Revoke  Certificates  page. 

•  A  Certificate  Revocation  Confirmation  page  will  appear  where  the  agent 
selects  the  revocation  reason,  an  invalidity  date  if  needed,  and  additional 
comments.  The  agent  then  clicks  Submit. 

•  The  certificate  is  then  marked  as  revoked  in  the  database,  an  email  is  sent 
to  the  certificate  owner,  and  an  updated  CRL  is  published. 

5,  Jobs  and  Notifications 

The  CMS  uses  email  alerts  to  notify  certificate  owners  of  successful  certificate 
request  processing  and  certificate  renewal  and  revocation.  Alerts  to  an  agent  can  also  be 
enabled  providing  the  agent  with  information  about  certificate  requests  in  queue  and 
summaries  of  renewal  notifications  that  have  been  sent.  To  enable  these  emails  to  be 
sent,  an  SMTP  connection  must  be  enabled  in  the  Netscape  Console  including  the  server 
name  and  port  number.  These  alerts  are  split  into  two  categories:  jobs  and  notifications. 
a.  Notifications 

The  CA  has  three  default  notifications.  Certificate  Issued,  Certificate 
Revoked,  and  Request  in  Queue.  Since  the  RA  lacks  the  ability  to  revoke  a  certificate, 
this  notification  is  not  available  from  the  RA.  Each  notification  can  be  enabled  or 
disabled  and  assigned  a  different  sender  (Figure  15).  Each  also  has  a  default  template 
stored  in  the  email  directory  of  the  CMS  instance  directory.  The  templates, 
certIssued_CA.html  for  example,  can  be  modified  to  include  information  relevant  to  a 
particular  PKI  deployment.  The  Request  in  Queue  notification  can  be  setup  through  a 
comma  delineated  list  to  send  to  multiple  RA  or  CA  agents. 
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Figure  15.  Notification  that  Can  Be  Enabled  in  the  CA. 

b.  Jobs 

Jobs  are  executed  using  the  Job  Scheduler,  which  is  setup  to  check  the 
configuration  of  job  instances  and  execute  them  at  a  specific  time.  The  CA  is  installed 
with  a  renewal  job,  a  request  in  queue  job,  and  an  unpublish  expired  certificates  job. 
These  jobs  can  be  configured  to  execute  based  on  five  criteria:  minute,  hour,  day  of 
month,  month  of  year,  and  day  of  week.  Figure  16  shows  some  of  the  other  areas  that 
can  be  configured  on  a  job. 
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Figure  16.  Job  Instance  Editor  for  the  Certificate  Renewal  Job 

Each  job  instance  refers  to  an  email  template  that  can  be  configured  to  provide  specific 
information  for  an  organization.  An  agent  can  create  and  register  custom  job  plug-in 
modules  and  job  instance  using  the  modules  via  the  Netscape  Console. 

6,  CRL  and  Publishing 

One  of  the  problems  that  arise  in  the  implementation  of  a  PKI  is  keeping  track  of 
revoked  certificates.  The  CMS  CA  has  an  internal  OCSP  responder  that  checks  the 
certificate  database  to  determine  if  a  certificate  is  valid;  however  other  applications 
require  a  Certificate  Revocation  Eist  against  with  to  verify  certificate  validity.  The  CA 
has  the  ability  to  publish  CRTs  to  several  different  issuing  points.  An  Issuing  Point  is  “a 
location  where  a  subset  of  all  the  revoked  certificates  are  maintained. ”43  It  is  also  an 
entry  in  the  Directory  Server  enabled  for  EDAP  communications.  Eor  the  purposes  of 
this  research,  the  CRE  was  published  to  the  MasterCRE  (Eigure  17)  and  LDAP 
publishing  was  enabled  via  the  Directory  Server. 


43  Ibid.,  p.  601. 
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Figure  17.  MasterCRL  Configuration  in  CA’s  Console 


Eaeh  CRL  Issuing  Point,  like  the  MasterCRL,  has  CRL  extensions  assoeiated 
with  it.  These  ean  be  enabled  or  disabled  based  on  the  implementation.  They  inelude; 

•  CRL  Reason  -  reason  for  the  eertifieate  revoeation 

•  Invalidity  Date  -  date  the  eertifieate  is  invalid 

•  CRL  Number  -  number  of  the  CRL 

•  Issuing  Distribution  Point  -  the  loeation  of  the  CRL 

As  seen  in  Ligure  17,  there  are  a  variety  of  settings  that  can  be  set  for  each  issuing 
point.  An  administrator  can  setup  one  issuing  point  that  only  issues  CRLs  for  CA 
certificates  and  another  issuing  point  that  only  issues  CRLs  about  user  certificates. 

Publishing  must  be  enabled  to  be  able  to  publish  a  CRL  to  a  directory  for  LDAP 
download  (Figure  18).  The  Mappers,  Publishers,  and  Rules  seen  in  Figure  16  provide 
configuration  information  about  the  location  and  policies  for  LDAP  publishing.  With 
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publishing  enabled,  the  CRL  is  then  saved  to  an  Issuing  Point  location  in  the  database  and 
can  be  pointed  to  in  the  CRL  Distribution  Point  certificate  extension  for  certificate 
validation  purposes. 


Figure  18.  Publishing  Enabled  on  the  CA 


7,  Certificate  Profiles 

A  certificate  profile  defines  everything  associated  with  the  issuance  of  a 
particular  type  of  certificate  including  the  authentication  method,  the 
certificate  content  (defaults),  constraints  for  values  associated  with  that 
content  that  can  be  contained  in  this  type  of  certificate,  and  the  contents  of 
the  input  and  output  forms  associated  with  the  certificate  profile.44 

Certificate  profiles  are  created,  modified,  and  deleted  through  the  administrative 
interface  of  the  CA  and  RA  (Figure  19);  however,  they  are  approved  and  disapproved  for 
end-entity  use  through  the  agent  interface.  From  the  agent  interface  of  the  RA  or  CA, 
Manage  Certificate  Profiles  is  selected.  A  profile  is  then  selected  from  the  list  of 
certificate  profiles  that  have  been  created  for  the  subsystem.  From  this  web  page,  profiles 
are  approved  or  disapproved  for  publication  to  the  end-entity  interfaces.  In  order  to  make 
modification  to  a  certificate  profile,  it  must  be  disapproved. 


44  Ibid.,  p.  431. 
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Figure  19.  Certificate  Profile  Instance  List  and  Plug-in  Selection  for  a  New  Profile 


Profile  instances  are  maintained  via  the  Administrative  Interface.  From  there  they  can  be 
added,  deleted,  viewed,  and  modified.  Each  certificate  profile  contains  certificate 
extensions  required,  inputs,  and  outputs  for  the  certificate.  Constraints  and  specific 
information  relating  to  an  extension  are  also  controlled  here  (Figure  20). 


Figure  20.  Certificate  Profile  Policy  Editor  for  Certificate  Extension  Addition 
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In  order  for  a  certificate  to  be  created  using  a  profile  on  the  RA,  the  profile  must  also 
exist  on  the  CA.  On  the  RA,  the  box,  End  User  Certificate  Profile,  must  be  set  to  true 
(Figure  21). 


Figure  2 1 .  Creation  of  Certificate  Profile  Instance 

On  the  CA,  this  box  must  be  set  to  false  so  that  the  request  is  not  processed  through  the 
associated  input  form  of  the  CA.  Each  profile  has  a  HTML  file  in  the  web-apps  ee 
directory.  Profile  information  is  also  stored  in  configuration  files  in  the  profiles  directory 
of  the  subsystem,  containing  information  to  the  certificate  extensions  and  constraints 
required  for  the  certificate.  Profiles  can  be  created  for  any  use  and  multiple  types  of 
certificates  can  be  issued  for  an  organization  based  on  a  person’s  role  in  the  organization. 

8,  Key  Archival  and  Recovery 

Key  archival  and  recovery  are  another  aspect  of  PKI  implementation.  Archiving 
a  certificate  owner’s  private  key  allows  for  him  to  recover  the  key  if  he  accidentally 
deletes  all  of  the  key  information  associated  with  his  certificate  but  he  still  needs  to  get  to 
the  information  that  he  encrypted  using  his  public  key.  Archiving  also  allows  a  company 
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to  recover  an  employee’s  private  key  to  decrypt  files  that  he  encrypted  once  he  has  left 
the  company.  This  research  was  supposed  to  create  a  working  model  of  the  Key  Archival 
(Figure  22)  and  Recovery  process,  however  there  was  a  problem  with  the  trust 
relationship  between  the  CA  and  the  DRM  that  prevent  successful  implementation. 

a.  Key  Archival 

As  discussed  in  the  Connecting  the  Subsystems  section,  the  transport 
certificate  of  the  DRM  is  added  to  a  JavaScript  function  in  the  ProfileSelect.template 
allowing  the  private  key  to  be  sent  with  the  certificate  request.  The  key  is  then  stored  in 
the  internal  token  of  the  DRM  encrypted  using  the  DRM’s  storage  key. 


Figure  22.  How  the  Key  Archival  Process  Works^s 
b.  Key  Recovery 

Archived  keys  remain  encrypted  until  key  recovery  agents  use  passwords 
to  unlock  what  is  called  password-splitting  mechanism. 

For  the  protection  of  the  storage  key  pair,  the  Data  Recovery  Manager 
supports  a  password-splitting  mechanism  called  m  of  n  secret  splitting  or 
sharing,  whereby  it  splits  the  PIN  that  protects  the  token  in  which  the 
storage  key  pair  resides  among  n  number  of  key  recovery  agents  and 


45  Ibid.,p.  203. 
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reconstructs  the  PIN  only  if  m  number  of  recovery  agents  provide  their 
individual  passwords;  n  must  be  an  integer  greater  than  1  and  m  must  be 
an  integer  less  than  or  equal  to  n.46 

During  the  DRM  subsystem  installation,  the  administrator  selects  the  m  of  n  scheme, 
where  m  is  the  number  of  recovery  agents  required  to  unlock  the  storage  key  and  n  is  the 
number  of  possible  recovery  agents  (Figure  23). 


Figure  23.  DRM  Recovery  Agent  Scheme 

CMS  allows  two  types  of  Agent-Initiated  Key  Recovery  Authorizations, 
local  and  remote.  Local  authorization  requires  the  Key  Recovery  agents  to  be  on  the 
computer  hosting  the  DRM.  If  the  correct  passwords  are  entered,  via  the  agent  interface, 
by  m  recovery  agents,  then  the  DRM  retrieves  the  key  and  returns  the  key  and  its 
corresponding  certificate  in  a  PKCS  #12  package.  Remote  Authorization  is  initiated  by 
one  recovery  agent.  Once  the  recovery  request  is  initiated,  the  DRM  sends  an  email  with 
a  specific  reference  number  to  all  of  the  recovery  agents.  The  required  number  of  agents 
must  individually  access  the  DRM’s  agent  interface  and,  using  the  reference  number. 


46  Ibid.,  p.  206. 
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authorize  the  key  reeovery.  The  PKCS  #12  package  containing  the  key  and  its  certificate 
are  returned  to  the  recovery  agent  initiating  the  request.  Figure  24  shows  the  agent- 
initiated  key  recovery  process. 


Data  Recovery  Manager 


Figure  24.  The  Agent- initiated  Key  Recovery  Process47 


47  Ibid.,  p.  209. 
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V.  VALIDATION  OF  CERTIFICATE  LIFE-CYCLE 

FUNCTIONALITY 

A,  LIFE-CYCLE  TEST  SETUP 

Installing  and  configuring  a  PKI  does  not  necessarily  mean  that  certificates  can  be 
created  and  used  successfully  for  the  purposes  of  confidentiality,  integrity,  authenticity, 
and  non-repudiation.  Testing  of  the  PKI  requires  validation  that  all  aspects  of  a 
certificate’s  life-cycle  work.  Certificates  have  essentially  three  phases,  creation,  use,  and 
termination;  either  by  revocation  or  by  normal  expiration.  To  test  the  functionality  of  this 
PKI,  20  certificates  were  taken  through  their  life-cycle,  with  each  being  used  to  test  one 
or  more  of  the  following  functional  requirements: 

•  Certificate  Request 

•  Request  Approval  and  Certificate  Creation 

•  Certificate  Download  by  Owner  and  User 

•  Certificate  Use  for  Digital  Signing  of  Email 

•  Certificate  Use  for  Encryption  of  Email 

•  Normal  Expiration  of  a  Certificate 

•  Revocation  for  Cause  (Administrative  Action) 

•  Revocation  by  Owner 

•  Certificate  Renewal 

•  Certificate  Revocation  Checking 

•  Certificate  Owner  Notification  of  an  Event 

•  Private  Key  Recovery  (Key  Escrow) 

•  Certificate  Archival  and  Retrieval  hollowing  Expiration 

In  order  to  test  the  digital  signature  and  encryption  aspects  of  the  certificates,  the  first  ten 
certificates  were  assigned  to  one  writer  and  the  second  ten  were  assigned  to  the  other. 
Table  4  lists  the  certificates,  their  assigned  user  and  the  aspect  of  the  life-cycle  they  were 
used  to  test.  There  is  duplication  in  the  tests  to  ensure  that  the  certificates  work  for 
multiple  users  and  that  each  aspect  works  consistently.  Keep  in  mind  that  aspects  of  the 
certificate  life-cycle  including  certificate  request  and  certificate  download  by  owner  were 
tested  for  each  certificate  simply  by  creating  the  certificate.  They  are  not  listed  for 
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individual  test,  because  without  successful  implementation,  they  rest  of  the  test  could  not 
be  performed.  Private  Key  Recovery  and  Key  Escrow  (Archival)  are  not  assigned  to 
specific  certificates  because  of  configuration  issues.  This  is  discussed  in  the  adjustments 
section  at  the  end  of  this  chapter. 
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Tests 

revocation  for  cause 

Userl 

Test4 

revocation  for  cause 

Userl 

Tests 

revocation  by  user 

Userl 

Teste 

revocation  by  user 

Userl 

Test? 

renewal  notification 

Userl 

Tests 

renewal  notification 

Userl 

Tests 

revocation  for  cause 

Userl 

TestIO 

revocation  for  cause 

Userl 

Test11 

Normal  expiration 

User2 

Test12 

Normal  expiration 

User2 

Testis 

revocation  for  cause 

User2 

Test14 

revocation  for  cause 

User2 

Testis 

revocation  by  user 

User2 

Testie 

revocation  by  user 

User2 

Test17 

renewal  notification 

User2 

Testis 

renewal  notification 

User2 

Testis 

revocation  for  cause 

User2 

Test20 

revocation  for  cause 

User2 

Table  4.  Test  Certificate  Use  and  User 

B.  CONDUCTING  THE  TESTS 

1,  Certificate  Request,  Request  Approval  and  Import 

Both  users  requested  certificates  for  each  of  their  10  certificates  via  the  RA’s  SSL 
end-entity  webpage  at  https://cdntest.cs.nps.naw.mil:  1037/  (Figure  25).  For  testing 


56 


purposes,  one  certificate  was  used  both  for  the  digital  signature  and  digital  encryption, 
also  known  as  a  dual  use  certilicate48,  and  was  created  by  selecting  the  Manual  User 
Dual  Use  Certificate  Enrollment  form. 


1  '3  Certificate  Management  System  - 1 

Microsoft  Internet  Explorer 

File  Edit  Wew  Favorites  Tools  Help 

Qsack  ~  Q 

yl)  Search  Favorites  Media 

A^ress  j.^  https://cdntest.cs,nps.navy,mil:1037/ra/ 

V  1  Q  Go  Links  ** 

Netscape  $ 

Certificate  Management 
System 

ManWlmTsfii*  /  Revnratinn 

.'  Retrieval 

Registration  Manager 

r 

List  Certificate 


Certificate  Profile 

Use  this  form  to  select  a  certificate  profile  for  the  request, 


Certificate  Profile  Name 

•  M.gnual  iJser  fiu.^l-usp  Certificate  Enrollment 

•  Manual  User  Signing  8-  Encryption  Certificates  Enrollment 

•  Manual  Server  Certificate  Enrollment 

•  Manual  Certificate  Manager  Signing  Certificate  Enrollment 

•  Manual  Registration  Manager  Signing  Certificate  Enrollment 

•  Manual  QCSP  Manager  Signing  Certificate  Enrollment 

•  Manual  Data  Recovery  Manager  Transport  Certificate 

Enrollment 

•  Directory-Based  User  Dual-Use  Certificate  Enrollment 

•  Agent-Based  Server  Certificate  Enrollment 


Description 

This  certificate  profile  is  for  enrolling  user  certificates, 

This  certificate  profile  is  for  enrolling  dual  user  certificates.  It 
works  only  with  Netscape  7.0  or  later. 

This  certificate  profile  is  for  enrolling  server  certificates. 

This  certificate  profile  is  for  enrolling  Certificate  Manager 
certificates. 

This  certificate  profile  is  for  enrolling  Registration  Manager 
certificates. 

This  certificate  profile  is  for  enrolling  OCSP  Manager 
certificates. 

This  certificate  profile  is  for  enrolling  Data  Recovery  Manager 
transport  certificates. 

This  certificate  profile  is  for  enrolling  user  certificates  with 
directory-based  authentication. 

This  certificate  profile  is  for  enrolling  server  certificates. 


https://cdntest, cs.nps, navy. mil;  1037/ra/profjleSelect?profiieId=raUserCert 


il^  Internet 


Figure  25.  SSL  End-Entity  Page  of  RA. 

Onee  the  eertifieate  request  has  been  made,  it  is  reeeived  by  the  RA  and  approved 
by  the  RA  agent.  The  request  is  then  signed  using  the  RA  signing  eertifieate  and  sent  to 
the  CA.  If  the  request  matehes  an  established  profile  and  the  certificate  matches  the  one 
associated  with  the  RA  user,  a  certificate  is  issued  and  an  email  is  sent  to  the  owner 
indicating  as  such.  With  a  compressed  time  schedule,  the  RA  agent  modifies  the  validity 
period  of  the  certificates  depending  on  the  purpose  of  the  test.  The  default  time  is  close  to 
seven  months  and  can  be  no  longer  than  365  days.  The  request,  as  seen  by  the  RA,  is 
shown  in  Figure  26.  The  approval  of  the  certificate  request  triggers  an  email  sent  by  the 
CA  to  the  owner’s  email  address  notifying  them  of  the  certificate  creation.  Once  this 


48  X.509. 
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email  is  received  the  owner  can  import  her  certificate  into  her  browser.  This  is  done  by 
clicking  on  the  retrieval  tab  of  the  RA’s  end-entity  interface  and  entering  the  appropriate 
request  number.  Other  people’s  certificates  can  also  be  manually  downloaded  by  users 
via  the  CA’s  end-entity  page.  Using  the  List  Certificates  link  of  the  Retrieval  tab,  they 
can  then  copy  the  base  64  encoding  of  the  certificate  to  a  text  file,  save  it  as  a  .pi 2  file 
and  then  import  that  .pi 2  file  into  their  browser.  All  of  the  certificates  were  successfully 
created,  imported  into  the  owner’s  browser  and  downloaded  by  a  user. 


Figure  26.  Certificate  Request  as  Viewed  from  the  RA’s  Agent  Interface. 

2,  Digital  Signature  and  Encryption  Testing 

Once  the  certificates  have  been  imported  into  the  Internet  Explorer  (IE)  browser, 
they  can  be  used  by  Microsoft  Outlook  for  digitally  signing  and  encrypting  email.  For 
each  of  the  20  certificates,  two  emails  were  sent  to  confirm  that  the  certificates  worked 
for  those  purposes  and  were  accepted  as  valid.  Figure  27  shows  the  message  security 
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properties  for  one  of  these  test  emails.  As  shown,  the  certificate  is  not  valid  for  either 
digital  signing  or  encryption.  There  is  a  disconnect  in  the  logic  of  Microsoft  and  CMS 
for  CRL  checking,  so  a  hard  wired  solution  was  used. 


Figure  27.  Message  Security  Properties  without  a  Valid  CRL. 
a.  Manually  Importing  a  CRL 

Outlook  was  unable  to  verify  the  validity  of  the  certificates  because  its 
locally  cached  CRL  had  expired,  and  it  was  unable  to  use  the  OCSP  service  provided  by 
the  CA.  As  an  alternative  revocation  check  solution,  the  user  can  manually  retrieve  and 
inspect  the  CRL  maintained  by  the  CA.  To  manually  retrieve  a  CRL,  the  user  would  go  to 
the  CA’s  end-entity  page  and  click  on  the  retrieval  tab.  On  the  left  side,  the  user  would 
select  Import  Certificate  Revocation  List.  Next,  select  the  radio  button  next  to  Import 
the  latest  CRL  to  your  browser  and  click  Submit  (Figure  28). 
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Figure  28.  CA  End-Entity  Page 


In  IE,  the  result  is  a  box  with  the  ehoiee  to  open  the  file  or  save  it  to  disk.  Onee  the  file  is 
saved  the  user  would  right-elick  on  it  and  seleet  install  CRL  and  follow  the  steps  of  the 
Certifieate  Import  Wizard.  Upon  eompletion  of  these  steps,  the  Message  Seeurity 
Properties  showed  that  the  eertifieate  was  valid  (Eigure  29). 
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Figure  29.  Successful  verification  of  certificate  after  a  manual  import  of  the  CRL. 

All  20  certificates  were  successfully  verified  for  their  validity  and  use  for  digital 
signatures  and  encryption. 

3,  Certificate  Expiration  and  Renewal 

Eight  of  the  certificates  were  used  to  verily  that  certificates  would  expire  at  the 
end  of  their  validity  period  that  the  certificate  owner  would  receive  an  email  reminding 
them  to  renew  their  certificate,  and  that  a  certificate  could  successfully  be  renewed. 

a.  Renewal  Notification 

The  CA  configures  the  job  scheduler  to  send  out  renewal  notifications  to 
the  owner  of  certificates  at  given  points  in  the  certificates  life-cycle.  For  the  purposes 
here,  certificate  renewals  were  sent  out  three  days  before  and  after  a  certificate’s 
expiration  date.  The  email  includes  the  expiration  date,  information  from  the  certificate, 
and  a  link  where  the  certificate  can  be  renewed.  One  such  email  is  pictured  in  Figure  30. 
The  CA  can  also  be  configured  to  send  a  renewal  notification  summary  to  an  agent  of  the 
CA.  All  of  the  certificate  renewal  notices  and  summaries  were  received  correctly. 
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Figure  30.  Certificate  Renewal  Notification  Email 
b.  Verification  of  Expiration 

Once  four  of  the  certificates  had  expired,  the  emails  sent  using  those 
certificates  were  checked  to  see  if  the  system  still  recognized  them  as  valid  certificates 
(Figure  31).  Successfully,  all  were  considered  invalid  because  they  had  expired. 


Figure  3 1 .  Verification  of  Certificate  Expiration. 
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c.  Certificate  Archival  and  Retrieval  Following  Expiration 

During  the  certificate  approval  process,  issued  certificates  are  saved  in  the 
Directory  Server  of  the  CA.  Certificates  will  be  kept  until  a  time  configured  by  the 
administrator  or  until  manually  deleted  by  an  administrator.  All  20  certificates  were 
successfully  archived  in  the  Directory  Server.  Certificates  that  have  expired  can  be 
recovered  via  the  agent  interface  of  the  CA  using  the  List  Certificates  link.  Once  the 
agent  has  navigated  to  the  certificate,  they  can  then  copy  the  base  64  encoding  into  a  .pi 2 
file  and  import  it  into  a  browser  as  needed.  All  certificates  are  archived  in  the  Directory 
Server  until  otherwise  deleted  based  on  a  time  limit  or  manually  deleted. 

d.  Certificate  Renewal 

As  mentioned  before,  once  a  certificate  comes  within  a  specific  time  range 
of  its  expiration  date,  email  notifications  are  sent  out  reminding  the  owner  to  renew  the 
certificate.  By  following  the  link  in  the  email,  the  owner  can  then  renew  their  certificate. 
To  renew  the  certificate,  they  simply  click  submit  (Figure  32)  and  then  select  the 
certificate  they  wish  to  renew  from  the  list  that  pops  up.  The  resulting  certificate  request 
is  forwarded  to  the  CA  via  the  RA  and  a  new  certificate,  valid  starting  at  the  date  the  old 
certificate  expires,  is  created  by  the  CA  and  imported  into  the  browser.  All  four  attempts 
at  certificate  renewal  were  successful  and  verified  by  sending  new  emails  (digitally 
signed  and  encrypted)  using  the  renewed  certificates. 


Figure  32.  User  Certificate  Renewal  End-Entity  Page 
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4,  Certificate  Revocation 

A  key  factor  in  the  effectiveness  of  a  PKI  system  is  to  be  able  to  revoke 
certificates  whose  corresponding  private  keys  have  been  compromised,  or  whose  owners 
have  been  either  transferred  from  an  organization  or  otherwise  lost  certain  privileges  that 
were  validated  by  the  certificate.  In  the  CMS,  there  are  two  methods  of  revocation,  user 
and  agent. 

a.  Revocation  by  User 

If  a  user  (or  owner)  determines  that  his  certificate  has  been  compromised 
in  some  form,  he  can  revoke  his  own  certificate.  This  is  done  by  going  to  the  secure  end- 
entity  interface  of  either  the  RA  or  CA  and  clicking  on  the  revocation  tab  (Figure  33). 
The  user  will  then  specify  the  reason  for  revocation  and  the  specific  certificate  to  be 
revoked.  The  CA  or  RA  will  process  the  request  and  the  revoked  certificate  will  show  up 
on  the  next  CRL.  In  our  tests,  all  of  the  user  revocations  were  successful.  This  was 
checked  by  entering  the  serial  numbers  of  the  certificates  at  the  Import  CRL  Revocation 
List  link  to  verify  that  the  certificates  were  on  the  revocation  list.  Unfortunately  due  to 
configuration  problems  with  Microsoft  products,  verification  that  a  certificate  had  been 
revoked  via  the  browsers  certificate  store  or  via  Outlook  for  failed. 
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Figure  33.  User  Certifieate  Revoeation  Form 

b.  Revocation  for  Cause 

A  CMS  agent  can  revoke  a  certificate  at  any  time  for  any  reason.  If  an 
employee  is  fired,  an  administrator  may  wish  to  terminate  their  certificate  at  the  earliest 
time  to  prevent  potential  loss  of  data  or  proprietary  information  belonging  to  the 
company.  This  can  be  done  using  the  agent  interface  of  the  CA.  The  agent  is  given  the 
same  reasons  for  revocation  as  the  user  is,  along  with  the  additional  option  of  “CA  key 
compromised”.  Once  the  certificate  has  been  revoked  it  will  show  up  on  the  next  CRL. 
The  test  of  eight  certificates  for  revocation  for  cause  were  successful  and  verified  using 
the  CA’s  end-entity  interface  as  was  done  for  testing  revocation  by  user  (above). 

c.  Revocation  Issues 

As  mentioned  in  the  previous  two  sections,  there  is  an  issue  with  CRL 
checking.  First,  to  enable  CRL  checking  in  IE  and  Outlook  some  configuration  changes 
need  to  be  made.  In  the  advanced  security  setting  of  Internet  Options  in  IE,  both  “check 
for  publisher’s  certificate  revocation”  and  “check  for  server  certificate  revocation”  need 
to  be  checked.  Eor  Outlook,  a  registry  key  must  be  added  to 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\  with  the  name 
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{7801EBD0-CF4B-1 1D0-851F-0060979387EA}.  The  next  step  is  to  create  the 
DWORD  registry  value  PolicyFlags  and  set  to  the  hexadecimal  value  of  10000.49  In 
addition  to  these  changes,  the  CA  must  be  considered  a  Trusted  Root  CA  by  the  operating 
system.  Although  these  changes  were  made,  there  is  still  a  mis-configuration  issue  that 
hinders  proper  CRF-based  revocation  checking.  As  discussed  in  the  Adjustments  section 
later  in  this  chapter,  the  CRF  Distribution  Point  Extension  that  was  not  included  in  the 
certificates  for  these  tests  may  help  with  this  issue. 

C.  SUMMARY  OF  RESULTS 

Table  5  is  a  summary  of  the  certificates,  the  tests  they  were  used  for  and  the 
results.  All  of  the  tests  were  successful.  The  cells  that  are  blacked-out  are  not  applicable 
to  the  test  in  that  column.  For  example  a  certificate  that  was  used  to  test  revocation  was 
not  used  to  test  renewal  after  that. 


Username 

Test  type 

test1 

normal  expiration 

test2 

normal  expiration 
revocation  for 

tests 

cause 

revocation  for 

test4 

cause 

tests 

revocation  by  user 

tests 

revocation  by  user 
Renewal 

test? 

notification 

Renewal 

tests 

notification 
revocation  for 

tests 

cause 

revocation  for 

test1 0 

cause 

test1 1 

normal  expiration 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 


yes  yes  yes 
yes  yes  Yes 

yes  yes 

yes  yes 
yes  yes 
yes  yes 

yes  yes  yes 

yes  yes  yes 

yes  yes 

yes  yes 
yes  yes  yes 


49  Interview  via  email  between  V.  Beach,  SPAWAR  Systems  Center  and  authors,  June  14,  2004. 
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Username 

Test  type 
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Table  5.  Summary  of  Certificate  Tests  Results 


D,  ADJUSTMENTS 


Though  all  of  the  tests  were  successful,  there  are  a  few  areas 
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streamlined.  The  first  issue  is  the  CRL  checking.  For  the  purposes  of  these  tests,  CRTs 
had  to  be  manually  installed  into  Windows.  The  ultimate  goal  for  revocation  checking 
would  be  to  have  a  CRL  Distribution  Point  Extension  in  the  certificate  that  used  Idap  to 
reach  the  CRL  published  to  the  CRL  Issuing  Point  in  the  Directory  Server.  This 


extension  should  also  be  added  to  the  CA  signing  certificate.  It  is  not  known  where  the 
problem  exists,  whether  it  is  a  Microsoft  implementation  issue,  a  Netscape 
implementation  issue,  an  X.509  PKI  design  or  configuration  issue,  or  some  combination 
of  these. 


Key  archival  and  recovery  is  an  area  that  was  not  tested  due  to  a  configuration 
issue.  Based  on  the  log  files  of  the  CA,  RA,  and  DRM  there  appears  to  be  no  archival 
request  being  sent  to  the  DRM  during  the  certificate  request  and  approval  process.  The 
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correct  certificate  for  the  DRM  Transport  Certificate  is  being  used  to  transport  the  private 
key  and  this  ean  be  verified  when  the  user  is  prompted  that  the  CA  wishes  to  arehive  the 
owner’s  private  key.  It  appears  that  there  is  a  trust  issue  between  the  CA  and  the  DRM 
that  prevents  the  key  archival  request  from  being  proeessed.  As  diseussed  in  Chapter  4, 
the  goal  of  key  arehival  is  to  store  the  private  key  of  the  eertifieate  owner  during  the 
eertificate  request  and  creation  proeess.  Recovery  would  then  inelude  retrieving  the 
private  key  and  its  corresponding  certificate  in  case  it  was  deleted  from  the  user’s 
maehine  or  to  open  doeuments  onee  a  user  has  left  his/her  organization.  In  the  DRM,  key 
reeovery  is  performed  by  reeovery  agents,  via  the  DRM’s  agent  interface,  using 
passwords  to  unloek  the  DRM  storage  key,  retrieve  the  decrypted  private  key,  and  ereate 
a  PKCS  #12  paekage  that  ineludes  the  private  key  and  its  eorresponding  eertifieate.  In 
the  CISR  PKI  lab,  there  is  a  trust  relationship  problem  that  prevents  the  storage  and 
retrieval  of  private  keys.  Once  the  eommunieation  between  the  CA,  the  RA,  and  the 
DRM  is  configured  eorreetly,  this  process  can  be  tested  properly. 
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VI.  CONCLUSIONS 


A.  OBSERVATIONS 

The  greatest  observation  of  PKI  that  ean  be  offered  at  the  eonelusion  of  this  thesis 
is  that  implementing  a  PKI  is  not  trivial.  For  an  administrator  to  fully  eomprehend  and 
manipulate  the  eapabilities  of  Netseape’s  CMS,  they  must  understand  Solaris,  PKI 
fundamentals  and  standards,  HTML,  Java,  JavaSeript,  LDAP  direetory  strueture,  and 
LDAP  eommunieations.  That  being  said,  instituting  a  CA  test  faeility  at  NPS  will  allow 
for  further  researeh  in  Publie  Key  Infrastrueture  and  thereby,  assist  DoD  in  aehieving  its 
goal  of  department-wide  use  of  PKI  and  Public  Key  Enabled  (PKE)  services.  This  thesis 
consisted  of  implementing  a  prototype  Certificate  Authority  and  it  supporting 
infrastructure.  In  it,  PKI  was  defined,  a  brief  history  of  public  key  cryptography  was 
provided,  and  certificate  usage  was  reviewed.  This  was  followed  by  a  discussion  of  the 
various  policy  considerations.  A  descriptive  overview  of  the  installation  was  provided 
with  the  ensuing  tests  well  documented.  The  road  to  establishing  a  public  key 
infrastructure  has  been  filled  with  many  unexpected  turns  and  a  few  pitfalls,  the  next 
section  will  discuss  some  of  the  issues  encountered. 

B,  ISSUES 

Software  and  hardware  selection  was  the  easy  part  in  that  the  Sun  Blade  lOO’s 
were  available  and  DISA  provided  access  to  the  Netscape  CMS  software.  The 
configuration  and  integration  of  the  hardware  and  software  became  the  major  challenge. 
The  first  problems  were  encountered  during  the  installation  of  the  CMS  software.  The 
final  installation  was  reached  after  reformatting  and  partitioning  the  hard  drives,  memory 
upgrades,  and  close  to  twenty  CMS  installation  attempts  using  different  deployment 
schemes  and  configurations.  These  problems  can  be  attributed  to  several  factors: 

•  A  lack  of  DoD  documentation  on  how  to  build  a  PKI 

•  A  lack  of  Netscape  documentation  on  how  to  build  and  implement  their 
PKI 

•  The  learning  curve  required  to  understand  the  Solaris  operating  system, 
PKI  fundamentals  and  the  components  used  to  build  the  CMS  software. 

Progression  through  the  installation  helped  to  provide  a  foundation  in  the  understanding 
of  the  CMS,  however  more  help  was  required  for  the  implementation  of  certificate 
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profiles,  CRL  publishing,  and  certificate  extensions.  Fortunately,  expert  technical 
assistance  was  obtained  from  Code  2873  at  SPAWAR  Systems  Center  San  Diego 
provided  a  large  knowledge  base  on  PKI  and  CMS. 

With  the  knowledge  acquired  from  SPAWAR  and  the  installation  complete,  it 
was  time  to  move  onto  the  configuration  of  the  PKI.  Trust  relationships  between  the  CA, 
the  RA,  and  the  DRM  were  established.  Certificate  profiles  were  adjusted  to  allow  users 
to  request  certificates  via  the  RA  and  to  allow  owners’  private  keys  to  be  archived.  The 
MasterCRL  was  enabled  and  configured  to  provide  access  to  a  CRL  issuing  point  and 
LDAP  publishing  of  this  CRL  was  also  enabled.  Though  the  majority  of  the  operational 
functionality  of  the  PKI  was  established  and  the  certificate  life-cycle  tested,  there  are  two 
areas  that  remain  for  follow  on  research  before  this  PKI  is  fully  functional. 

C.  FOLLOW  ON  WORK 

During  the  testing  of  the  PKI  operations  there  were  two  areas  that  were  identified 
as  requiring  further  work.  Certificate  validation  is  the  first  concern.  Microsoft  products 
must  be  manually  configured  to  perform  CRL  checking  as  discussed  in  Chapter  5.  One 
way  to  facilitate  this  process  is  to  include  the  Certificate  Revocation  List  Distribution 
Point  certificate  extension  in  the  certificates.  This  extension  must  be  included  in  the  CA 
signing  certificate  as  well  as  user  certificates.  The  extension  points  to  the  location  of  the 
CRL  in  the  Directory  Server  and  this  CRL  issuing  point  must  be  readable  by  ah  users  to 
allow  for  the  revocation  checks  to  occur.  Correct  implementation  of  this  extension  and 
CRL  publishing  will  streamline  the  CRL  checking  issues  and  make  the  PKI  more 
effective  for  future  research. 

The  second  operability  issue  is  the  escrow  and  recovery  of  private  keys,  what 
CMS  refers  to  as  “key  archival.”  Key  archival  is  the  process  through  which  private  keys 
are  stored  in  the  DRM  during  the  certificate  request  and  approval  process.  As  discussed 
in  Chapter  4,  private  keys  are  encrypted  using  the  DRM’s  storage  certificate  and  then 
stored  in  the  DRM’s  Directory  Server.  The  current  configuration  requires  two  recovery 
agents  (of  a  possible  four)  to  enter  their  passwords  to  unlock  the  storage  encryption.  A 
PKCS  #12  package  containing  the  private  key  and  its  associated  certificate  is  then 
created.  Currently,  a  trust  issue  prevents  the  key  archival  request  created  by  the 

certificate  request  from  being  processed.  With  no  keys  archived,  key  recovery  cannot  be 
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tested.  Reissuing  the  eertifieates  for  the  CMS  subsystems  using  the  Certifieate  Setup 
Wizard  and  making  the  neeessary  eonfiguration  adjustments  may  fix  the  problem.  This 
funetionality  is  important  for  any  environment  that  deems  private  key  reeovery  an 
essential  aspeet  of  its  PKI. 

The  ultimate  goal  of  this  projeet  was  to  ereate  a  PKI  test  bed  in  the  NPS  CISR  lab 
that  would  enable  testing  of  eurrent  DoD  PKI  issues.  Ideally,  with  the  two  problems 
deseribed  above  fixed,  other  areas  of  PKI  researeh  ineluding  validation,  verifieation,  CRL 
distribution,  and  Online  Certifieate  Status  Protoeol  (OCSP)  ean  be  performed,  thus 
improving  the  DoD’s  ability  to  seeure  eommunieations  in  a  eomputer  network 
environment. 
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APPENDIX 


This  appendix  is  the  User’s  Guide  to  the  CISR  PKI.  It  outlines  installation 
proeedures  and  provides  step  by  step  instruetions  for  the  performanee  of  software 
eonfiguration  and  maintenanee.  The  User’s  Guide  is  intended  for  use  in  follow  on 
research  or  by  students  during  cyber  defense  exercises. 
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GETTING  STARTED 


Getting  Started 


Prepanngyoptr  ^stem  for  installation  Netscape's  Certificate 
Mana^ment  System. 

The  installation  and  configuration  of  Netscape’s  Certificate  Management 
System  (CMS)  requires  some  preparation  of  both  the  user  and  computer(s)  on 
which  the  system  will  be  installed. 

Familiarization  with  Solaris  8 

Netscape’s  CMS  6.1  currently  runs  on  Solaris  S.  A  working  knowledge  of  this 
operating  system  is  important.  A  good  knowledge  of  UNIX  is  beneficial,  however 
there  are  some  differences  between  Solaris  and  UNIX  commands  and  system 
information.  The  hst  of  references  below  can  help  to  increase  your  knowledge  of 
Solaris. 


Solaris  References 

•  Solaris  Solutions  for  Systems  Administrators  2”'* 
Edition  by  Sandra  Henry -Stocker  and  Evan  R.  Marks 

•  Sun  Systems  website  -  www.snn.  com/documentation 


NFS  also  boasts  several  Solaris  experts  including  Mike  Williams  and  Paul  Clark. 
They  have  experience  with  Sun  systems  and  can  provide  some  technical  support  and  if 
nothing  else  can  point  you  in  the  right  direction  to  find  a  solution  to  a  problem. 


Preparing  the  Computer 

Adjusting  Network  Configuration 

Our  recommendation  is  to  begin  with  a  clean  installation  of  Solaris  8,  especially  if  the 
computer  has  been  inherited  from  another  project.  After  installing  the  operating 
system,  there  are  a  couple  of  files  that  need  to  be  created  or  modified  to  setup  DNS 
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capabilities  and  the  remainder  of  the  networking  parameters,  if  they  were  not  done 
successfully  during  the  Solaris  Installation.  The  network  parameters  used  below  are 
from  a  test  setup.  The  network  the  PKI  is  being  installed  on  will  determine  the  default 
router  and  DNS  seiver(s)  used. 

1 .  Login  or  su  to  root  and  open  a  terminal  window. 

2.  Change  directories  to  /etc 

3.  Add  the  defaultdomain  file.  This  file  tells  the  computer  which  domain  it  is 
associated  with  and  is  needed  for  CMS  installation. 

a.  vi  detiialtdomain 

b.  Add  the  fine  “cs.nps.nayy.mir’ 

c.  Save  and  close  the  file 

4.  Add  the  defiialtrouter  file.  This  file  tells  the  computer  the  IP  address  of  the 
router,  which  it  communicates  with. 

a.  vi  defaultrouter 

b.  Add  the  line  “131.120.8.1” 

c.  Save  and  close  the  file 

5.  Modify  or  create  the  resolv.conf  file.  This  file  contains  the  addresses  of  the 
DNS  servers  that  the  computer  can  resolve  its  name  and  IP  address.  This  is 
another  key  file  for  CMS.  If  preferred  you  can  setup  a  DNS  server  on  the 
computer  you  are  using,  although  this  is  not  recommended  mainly  because  it 
is  a  complicated  process.  The  resolv.conf  file  should  look  as  follows: 


Window  Edit  options 


jdelpi 


Bomain  cs.nps.navy.iril 
nameserver  131.120.18.40 
namesBrver  131.120.18.41 


"resolv.conf"  [Read  only]  3  lines.  73  characters 


6.  Ensiire  that  your  IP  address  and  subnet  mask  are  correct. 
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a.  List  the  cmrent  configuration  of  the  NIC. 

i.  ifconfig  -a 


b.  Modify  the  address  or  subnet  mask  as  needed 

i.  ifconfig  eiiO  inet  13 1. 120.8.203 

1 .  eriO  is  the  name  of  the  NIC  card 

ii.  ifconfig  eriOnetmask  255.255.252.0 

Creating  Groups  and  Users 

Once  the  network  configuration  has  been  setup,  groups  and  users  that  wiU  be 
associated  with  running  CMS  need  to  be  created.  This  group  wfil  have  access  to  the 
consoles  and  files  that  run  CMS .  CMS  can  also  run  as  one  of  these  users  depending 
on  your  setup.  It  is  suggested  that  you  have  a  group  with  a  user  to  run  CMS  as  and 
another  user  that  wfil  manage  the  CMS  installation. 

1 .  As  root,  change  directory  to  /etc 

2.  Open  the  group  file  in  vi  or  another  editor 

3.  At  the  end  of  the  file  add  the  new  group  name,  a  number  that  wfil  serve  as  the 
group  identifier  and  any  users  that  wfil  belong  to  that  group.  In  the  picture 
below,  the  cmsadmin  group  has  been  added  with  a  group  id  of  1024  and  the 
users:  dengards,  amkeUy,  and  snoopy. 
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4.  Create  the  user,  profile  and  set  the  password.  This  should  be  repeated  for  all 
of  the  users  that  were  added. 


a.  useradd  -g  cmsadmin  -m  -s  /sbrn/sh  -d  /export/home/username 
username 

b.  q)  /etc/skehlocal.profile  /expoit/home/username/ .profile 

c.  passwd  username 

Extracting  CMS  Software 

The  DoD  is  currently  using  CMS  version  6.1  on  all  of  its  Certificate  Authorities  (CA). 
This  is  the  version  referred  to  for  the  duration  of  this  user’s  manual.  The  software  can 
be  found  at  the  DoD  Site  License  -  Netscape  Software  Download  Site  at 
http:  .’  netscape .mtelhgent.net-'r^^  The  user  must  register  and  sign  on  to  be  able  to 

use  the  site  and  perform  downloads.  There  is  also  a  cdrom  containing  the  software  in 
the  CISR.  There  are  a  couple  of  options  for  getting  the  software  onto  the  Sun  box. 
Assuming,  the  network  cormection  is  functional,  the  software  can  be  downloaded 
directly  to  the  computer.  If  there  is  no  connection  to  the  outside  world,  use  a  cdrom  or 
ftp  the  file  from  a  computer  with  outside  access  to  the  Sun  box. 

1 .  Copy  the  cms61  .tar  file  to  /export/home/  or  another  directory 

2.  Extract  the  files  -  tar  xvf  vms61  .tar 

The  computer  is  now  ready  to  install  the  CMS  software. 
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Chapter 


Installation 


Imtalb^the  Cer^a^Mam^rtmtSysim  and  CMS  Instance  Caf^oahm 

Installing  Netscape’s  Certificate  Management  System  (CMS)  is  feirly  simple  once 
you  decide  what  your  deployment  scheme  will  be.  Though  you  can  have 
multiple  CMS  instances  in  one  server  group,  our  recommendation  is  to  install 
multiple  server  groups  and  coimect  via  the  Directory  Server.  The  CISR  lab  is 
setup  with  a  Registration  Manager  in  a  server  group  on  Tefiiut  and  a  Certificate 
Manager  and  a  Data  Recovery  Manager  in  individual  server  groups  on  Maat. 

CMS  is  installed  with  an  administration  server  instance,  a  directory  server  irrstance 
and  a  certificate  management  server  instance.  The  administration  server  runs  the 
console  used  to  mairage  the  servers  and  the  directory  server  keeps  track  of  certificates, 
requests,  CRTS,  and  user  infomration.  The  CMS  instance  wUl  be  configured 
depending  on  the  subsystem  you  are  running  and  contains  the  agent,  end-entify,  and 
administration  web-pages,  along  with  the  pohcies  and  profiles  associated  with  them. 

Installing  the  Netscape  Servers 

The  installation  begins  by  instaUing  the  software  for  the  administration  server, 
directory  server  and  the  certificate  management  system.  This  portion  is  split  into  two 
sections,  one  if  you  are  installing  the  first  server  group  on  a  machine  and  a  second  if 
you  are  installing  another  server  group  on  a  machine  which  already  has  a  server  group. 
Multiple  instances  of  the  directory  server  and  CMS  can  be  nm  in  one  server  group. 
The  choice  for  multiple  servers  or  multiple  CMS  instances  in  one  server  group 
depends  on  the  deployment  scheme.  Further  explanations  of  the  screens,  questions, 
and  configuration  information  asked  for  during  this  phase  of  the  installation  are 
located  in  the  Administrator’s  Guide  Netscape  Certificate  Management  System, 
Version  6.1. 

First  Server  Group  Installation 

1 .  Open  a  terminal  window  and  change  directories  to  the  directory  you  extracted 
the  CMS  installation  files  to. 

2.  Type:  ./setup  -k  (this  flag  keeps  a  setup  log  file  that  you  can  read  later) 
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3 .  Answer  yes  to  continue  the  installation. 


4.  Answer  yes  to  accept  the  license  agreement. 

5.  Select  1 


Terminal  '■  1“ 


6.  Select 2 -Typical  Install 
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7.  Accept  the  default  location  or  choose  a  different  location 

8.  Select  the  defaults  for  the  next  six  screens  about  which  Netscape  servers  and 
their  components  to  install. 


Terminal 


9.  Enter  the  fully  quahfied  domain  name  for  the  computer. 

1 0.  Enter  system  user  that  the  servers  will  run  as. 

1 1 .  Enter  system  group  that  the  system  user  belongs  to. 
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1 2.  No,  you  do  not  want  to  register  with  an  existing  directory  server. 

13.  No,  you  do  not  want  to  use  another  directory  to  store  your  data. 

1 4.  Select  the  port  number  that  the  directory  server  instance  will  use.  The  de&ult 
is  given  as  389  which  is  a  standard  Idap  port.  For  security  purposes,  this  port 
should  be  changed  to  greater  than  1024  so  that  the  directory  server  can  run  as 
your  system  user  id  instead  of  root.  If  you  choose  to  run  directory  server  as 
root,  the  port  selected  must  be  389. 
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15.  Enter  an  identifier  for  the  directory  server,  typically  the  computer  name,  but  it 
can  be  anything. 


16.  Enter  the  administrator  id  and  password  that  will  be  used  to  log  into  the 
administration  sever  via  the  console  to  control  the  servers. 


1 7.  Accept  the  defaults  for  the  Directory  Manager  Distinguished  Name, 

1 8.  Select  the  default  domain  name  for  the  directory  manager. 

1 9.  Enter  the  password  of  the  system  user. 

20.  Enter  the  administration  domain.  The  correct  portion  of  the  fully  quafified 
domain  name  should  come  up  as  the  default. 

21.  Enter  the  administration  port  number.  This  number  should  be  above  1024  and 
the  default  is  acceptable. 

22.  For  security  purposes,  run  the  administration  server  as  the  system  user  id. 
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23.  Enter  the  identifier  for  the  CMS  instance  in  the  server  group. 

You  should  get  the  following  output  and  then  you  are  ready  to  proceed  to  the 
configuration  of  the  CMS  instance  or  a  second  server  group  installation. 
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Second  (Multiple)  Server  Group  Installation 

1 .  Open  a  terminal  window  and  change  directories  to  the  directory  you  extracted 
the  CMS  installation  files  to. 

2.  Type:  ./setup  -k  (this  flag  keeps  a  setup  log  file  that  you  can  read  later) 

3 .  Answer  yes  to  continue  the  installation. 

4.  Answer  yes  to  accept  the  license  agreement. 


13 


88 


N5TALLING  CMS  SOFTWARE 


5.  Select  1 

6.  Select  3  -  Custom  Install 

7.  Accept  the  default  location  or  choose  a  different  location 

8.  Select  the  delaults  for  the  next  six  screens  about  which  Netscape  servers  and 
their  components  to  install. 

9.  Enter  the  fully  quahfied  domain  name  for  the  computer. 

1 0.  Enter  system  user  that  the  servers  will  run  as. 

1 1.  Enter  system  group  that  the  system  user  belongs  to. 

12.  Yes,  you  do  want  to  register  with  an  existing  directory  server. 

13.  Enter  the  fully  qualified  domain  name  and  port  number  of  the  directory  server 
of  the  first  server  installation. 

1 4.  Enter  the  admin  id  and  password  for  the  directory  server  you  are  cormecting 
to. 

15.  Select  the  port  number  that  the  directory  server  instance  will  use.  The  default 
is  given  as  389  which  is  a  standard  Idap  port.  For  securily  purposes,  this  port 
should  be  changed  to  greater  than  1 024  so  that  the  directory  server  can  run  as 
your  system  user  id  instead  of  root.  If  you  choose  to  run  directory  server  as 
root,  the  port  selected  must  be  389 . 

1 6.  Enter  an  identifier  for  the  directory  server,  typically  the  computer  name,  but 
can  be  anything. 

1 7.  Accept  the  default  dns. 

1 8.  Select  the  default  domain  name  for  the  directory  manager. 

1 9.  Enter  the  password  of  the  system  user. 

20.  Choose  either  yes  or  no. 

21.  Choose  either  srrggest  or  none. 

22.  Choose  no. 

23.  Enter  the  administration  port  number.  This  number  should  be  above  1024  and 
the  default  is  acceptable. 
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24.  Enter  the  IP  address  of  the  computer  on  which  you  are  installing  the  software 
or  leave  blank. 

25.  Enter  the  system  user  id. 

26.  Enter  the  identifier  for  the  CMS  instance  for  the  second  server  group. 

Configuring  the  CSM  Instance 

The  CMS  instance  now  needs  to  be  configured  for  the  subsystem  you  are  running  on 
that  particular  server  group  or  just  for  that  particular  instance.  CMS  has  four  possible 
subsystems  that  it  can  run  as:  a  certificate  manager  (CA),  a  registration  manager  (RA), 
a  data  recovery  manager  (DRM)  (also  referred  to  as  a  key  recovery  archive  (KRA)  in 
some  environments),  and  an  online  certificate  system  manager  (OCSM).  The  CA 
subsystem  also  has  two  possible  setups,  one  for  a  root  CA  and  one  for  a  subsidiary 
CA.  Each  subsystem  has  a  different  installation  wizard  however  the  first  few  steps  are 
the  same. 

1.  From  a  terminal  window,  change  directories  to  the  main  server  groups 
directory.  Type  ./startconsole  to  start  the  Netscape  console.  Enter  the  user 
name  and  password  for  the  administration  id  used  for  the  administration  server 
during  installation. 

2.  Double  click  on  the  CMS  instance  you  will  be  working  with. 

3 .  Chck  next. 

4 .  Enter  a  logon  token. 

5.  The  recommendation  is  to  select  the  defeult  of  creating  a  new  internal 
database.  Enter  the  required  information. 

a.  Note:  If  the  installation  hangs  during  this  proeess.  Halt  the  system 
fiom  a  terminal  window.  Restart  the  slapd  server  and  that 
administration  server.  Remove  the  directory  of  the  internal  database,  it 
will  have  -db  after  the  instance  name.  Finally,  start  the  console  and 
restart  the  setup  wizard. 
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6.  Administrator  Information:  Enter  the  administrator  id  and  password.  Leave 
the  allow  multiple  roles  for  users  checked. 

7.  Select  the  subsystem  you  wiU  be  installing. 
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Certificate  Manager 

1.  Since  you  have  not  setup  a  DRM,  answer  no  to  do  you  want  to 
coimect  the  current  subsystems  to  a  remote  data  recovery  manager. 

2.  Enter  the  serial  nimiber  range. 

a.  Root  CA:  The  starting  serial  niunber  should  be  left  at  0x1.  If 
you  are  not  installing  a  subsidiary  CA,  you  can  leave  the 
ending  serial  number  blank.  If  you  are  adding  a  subsidiary 
CA,  our  recommendation  is  to  set  an  upper  bound  for  the  Root 
CA. 
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b.  Subsidiary  CA:  The  starting  serial  number  should  be  the  Root 
CA’s  ending  serial  number  plus  one.  The  ending  serial 
number  can  be  left  blank  or  if  there  are  multiple  subsidiary 
CAs  an  upper  boimd  should  be  set  so  that  the  subsidiary  CAs 
are  not  issuing  numbers  in  the  same  range. 

3.  Leave  the  internal  OCSP  service  box  checked.  You  can  enable  and 
disable  this  box  via  the  CMS  console  if  you  choose  to  use  it  later,  but 
if  the  box  is  left  checked  an  OCSP  certificate  will  be  created  during 
install  and  the  OCSP  responder  information  will  be  setup. 
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4.  Select  the  ports  that  the  various  services  will  be  running  on.  As  long 
as  they  are  above  1024  and  aren’t  being  used  by  other  daemons,  any 
number  will  work. 


5.  For  the  Root  CA  select  to  create  a  self-signed  CA  Certificate.  If  you 
are  instahing  a  subsidiary  CA,  you  will  need  to  follow  the  instructions 
for  acquiring  a  certificate  located  in  the  both  the  DRM  (#6  -  15)  and 
RA  (#23)  sections. 

6.  Enter  the  Key-Pair  Infoimation.  If  you  are  using  a  cryptographic 
module  you  can  select  an  external  token.  The  key  length  can  be  1024, 
2048  or  a  custom  bit  length. 
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a.  Token:  Internal 

b.  Key  Type:  RS  A 

c.  Key  Length:  2048 

7.  Select  a  Message  Digest  Algorithm:  SHAl 

8.  Enter  the  Subject  Name  information  for  the  Certifieate  Manager  CA 
Signing  Certificate.  Enter  as  much  or  as  httle  information  as  you 
want  You  should  include  a  common  name,  the  organizational  unit, 
the  organization  and  the  country. 

9.  Modify  the  Validity  Period  as  needed. 

10.  Keep  the  default  Certificate  Extensions. 
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11.  CUcknext. 

1 2.  Select  sign  SSL  Certificate  with  my  CA  Signing  Certificate. 

13.  Modify  key-pair  information  for  the  SSL  Server  Certificate  as  needed. 
The  key  length  cannot  exceed  that  of  the  CA  Signing  Certificate. 

14.  Select  the  Message  Digest  Algorithm. 

15.  Enter  the  subject  name  information  for  the  SSL  Server  Certificate. 
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16.  Modify  the  Validity  Period.  It  shoidd  not  extend  past  the  validity  of 
the  CA  Signing  Certificate. 

17.  Accept  the  defeult  certificate  extensions. 

18.  Chcknext. 

19.  Check  the  remove  password.conf  file.  As  long  as  you  have 
maintained  records  on  the  passwords  you  are  using,  remove  this  file, 
sinee  they  are  stored  in  the  clear  for  use  when  starting,  stopping  and 
restarting  the  servers.  There  is  another  location  where  the  information 
is  encrypted  and  saved. 

Once  you  have  completed  the  setup  of  the  root  CA,  the  first  agent  must  be  eruoUed. 
Members  of  the  agent  group  have  access  to  the  agent  services  portion  of  the  CA 
website  and  the  CMS  console.  Agents  can  add  and  change  certificate  profiles  or 
pohcies,  issue  and  revoke  certificates  and  control  other  aspects  of  the  sub^stem.  The 
first  agent  enrollment  is  only  needed  for  the  CA  subsystem.  FoUow  the  instructions 
below  to  setup  the  first  agent 

1 .  Open  a  browser  and  go  to  https:/ host:adrninpott  ca  atltrrinEmoll.htirrl 

2.  Fin  out  the  information  on  the  form.  Remember  that  the  validity  date  cannot 
be  past  the  vahdity  date  of  the  CA  signing  certificate  and  the  key  length  cannot 
be  longer  than  that  of  the  CA’s.  You  wfll  need  to  enter  a  password  for  the  key 
storage  used  in  the  browser. 

3.  The  CA  wfil  then  issue  the  certificate  and  you  will  now  have  access  to  the 
agent.  Copy  the  base  64  encoding  of  the  certificate  from  the  page  in  the 
browser. 

4.  Open  the  CMS  console,  by  double  choking  on  the  instance  in  the  Netscape 
Console. 

5 .  CHck  on  the  configuration  tab. 

6.  Chck  on  Users  and  Groups. 

7.  Select  the  user  you  entered  as  the  administrator. 
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8.  Click  Certificates. 

9.  Click  Import. 


10.  Click  Copy  fiom  Clipboard  to  copy  the  64-base  encoding  fi:om  step  #3  into  the 
window. 

1 1 .  Click  Done.  Note:  If  the  certificate  is  rqected  for  some  reason,  simply  repeat 
the  copy  and  import  process. 

The  Root  CA  is  now  ready  to  be  configured. 

Data  Recovery  Manager 

1.  Select  Data  Recovery  Manager  as  the  subsystem. 
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2.  Enter  the  port  numbers  for  both  the  SSL  administration  port  and  the  SSL 
agent  port.  Make  sure  that  these  ports  are  not  already  being  used  by 
another  subsystem  or  server  on  the  eomputer. 

3 .  Enter  the  Key-Pair  Information. 

a.  Token:  internal 

b.  Key  type:  SHAl 

e.  Key  length:  2048  bits 

4.  Enter  the  subject  name  information  for  the  DRM’s  certificate. 

5 .  Accept  the  de&ult  certificate  extensions . 

6.  Choose  to  send  the  request  to  a  remote  CMS  now. 

a.  Enter  the  information  for  the  root  CA. 

b.  Click  next. 
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7.  In  a  web  browser,  go  to  the  agent  service  page  of  the  root  CA,,  using  the 
port  number  entered  in  the  CMS  instance  setup.  The  browser  will  prompt 
for  the  use  of  a  cerhfieate,  select  the  certificate  created  for  the  first  agent. 

8.  On  the  left  side  of  the  page  click  on  fist  requests. 
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9.  Click  Find. 

10.  Click  Details  for  the  request  number  that  was  generated  in  the  install. 

11.  Change  the  algorithm  to  SHAl  with  RSA. 

12.  ChckDoIt. 

13.  Return  to  the  DRM  instance  setup. 

14.  Chcknext. 

15.  Select  the  certificate  is  at  the  CMS  where  your  request  was  sent.  The 
setup  program  should  have  forwarded  the  information  to  this  page.  The 
program  will  then  get  the  certificate  from  the  CA  and  install  it 
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16.  Enter  the  number  of  recovery  agents  required  and  the  total  number  of 
recovery  agents.  This  can  be  changed  after  the  installation. 

17.  Enter  the  username  and  password  information  for  the  number  of  recovery 
agents  that  were  specified. 

1 8.  Accept  the  defeult  key-pair  information  for  the  SSL  certificate. 

1 9.  Enter  the  subj  ect  name  information  for  the  certificate. 

20.  Accept  the  default  certificate  extensions  for  the  certificate. 
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2 1 .  Select  generate  a  PKCS 10  request. 

22.  Select  send  the  request  to  a  remote  CMS  now,  using  the  information  for 
the  root  CA. 

23.  Create  and  install  the  certificate  by  repeating  steps  7  through  15  Hsted  in 
this  section. 

24.  Chcknext. 

25.  Select  to  remove  the  password.conf  file. 

Registration  Manager 

1 .  Enter  the  information  for  the  root  CA. 

2.  Chck  yes  and  enter  the  information  for  the  Data  Recovery  Manager. 

3 .  Enter  the  network  configuration  information  for  the  RA.  Ensure  that  the 
ports  are  not  in  use . 

4.  Accept  the  defeult  Key- Pair  information. 

5 .  Enter  the  subj  ect  name  information  for  the  RA  certificate. 

6.  Accept  the  defeult  certificate  extensions. 

7.  Select  next. 

8.  Select  send  the  request  to  a  remote  CMS  now  and  enter  the  information  for 
the  root  CA. 

9.  Repeat  the  step  7  through  1 5  hsted  in  the  Data  Recovery  Manager  section, 
to  create  and  install  the  RA  certificate. 

10.  Accept  the  deferrlt  key-pair  information  for  the  SSL  certificate. 

11.  Enter  the  subject  name  information  for  the  SSL  certificate. 

12.  Accept  the  de&rrlt  certificate  extensions. 

13.  Select  generate  a  PKCS  10  request  and  click  next 

1 4.  Again  foUow  steps  7  through  1 5  from  the  DRM  setup  to  create  and  install 
the  SSL  certificate  for  the  RA. 

15.  Select  to  remove  the  password.conf  file  and  chck  next 
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16.  If  you  will  be  using  the  same  user  as  the  agent  for  the  RA  as  for  the  CA, 
you  will  need  to  export  the  certificate  from  the  browser  on  the  CA  and 
import  it  to  the  browser  on  the  RA  and  then  copy  the  certificate 
information  into  the  user  field  in  the  Users  and  Groups  in  the  RA  console. 
Refer  to  Chapters  3  -  User  Certificates  and  5  -  Users  and  Groups  for  more 
information. 

Connecting  the  Subsystems 

ConncKrtors 

In  order  for  the  subsystems  to  talk  with  one  another,  the  cormectors  they  use 
must  be  enabled.  The  CA  must  enable  its  cormection  to  the  DRM.  The  RA  must 
enable  its  coimections  to  both  the  CA  and  the  DRM.  The  steps  below  discuss  how  to 
enable  a  connection. 

1 .  To  set  the  coimections  go  to  the  Configuration  tab  and  chck  the  subsystem  you 
wish  to  coimect,  RA  or  CA. 

2.  Chck  the  connector. 

3 .  S  elect  the  coimector  you  want  to  change  then  chck  the  Edit  tab. 


4.  Select  Enable 

5 .  Enter  the  host  information  and  a  period  in  the  timeout  section.  Chck  OK 

6.  Repeat  for  the  remaining  connections. 
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Trusted  Manager 

The  Trusted  Managers  group  is  a  default  group  whose  users  are  other 
subsystems  that  are  trusted  by  this  subsystem.  For  the  CA  to  be  able  to  process 
requests  from  the  RA,  the  RA  must  be  a  Trusted  Manager.  For  the  DRM  to  process 
requests  from  the  CA  and  the  RA,  they  both  must  be  trusted  managers.  This  section 
will  discuss  how  to  add  a  subsystem  as  a  Trusted  Manager.  For  more  information  on 
Users  and  Groups  refer  to  Chapter  5  of  this  guide. 

1 .  On  the  console  chck  the  configuration  tab.  Select  User  and  Groups. 

2.  Chck  Add  in  the  Users  tab. 

3 .  Ffil  in  the  user  information  as  required.  The  Full  Name  must  be  the  fuUy 
quahfied  domain  name  (FQDN).  Password,  email,  and  phone  information  are 
not  required.  Leave  the  User  State  equal  to  one. 

4.  Select  Trusted  Managers  for  the  group.  Chck  Ok 


5.  Select  the  newly  created  user  and  chck  Certificates. 

6.  Chck  Import. 

7.  Go  to  the  end-entitv  for  the  CA  at:  https:.7cdiiintemet.npc.naw.mil:  1 027 

8.  Chck  Retrieval  tab. 
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9.  Qick  Find  and  locate  the  certificate  for  the  saibsystem  being  setup  as  a  Trusted 
Manager.  Refer  to  the  Hst  below  for  help  in  selecting  the  correct  certificate. 

a.  RA  user  on  CA  -  RA  signing  certificate 

b.  CA  user  on  DRM  -  CA  SSL  Server  certificate 

c.  RA  user  on  DRM  -  RA  signing  certificate 

10.  Copy  the  base  64-encoding. 

1 1 .  Go  back  to  the  Import  Certificate  window  and  chck  Paste  fi'om  Clipboard. 

12.  Qick  Ok. 


13.  Click  Done. 


Adding  the  KRA  Transpeit  Certifleate 

To  be  able  to  perform  Key  Archival,  the  certificate  enrollment  forms  must 
have  the  DRM  Transport  Certificate.  The  certificate  must  be  added  to  both  the  CA 
and  RA  ProfileSelect. template. 

1 .  Open  the  agent  interface  of  the  CA  via  a  web  browser. 
https://cdnrntemet.cs  .nps.naw.miliSl  00 

2.  Chck  List  Certificates  and  Find.  Navigate  to  the  DRM  Transport  Certificate. 

3 .  Copy  the  base  64  encoding  for  the  certificate.  Do  not  include  the  begin  and 
end  certificate  tags. 

4.  Open  a  text  editor  and  open  the  ProfileSelecttemplate  located  in 
/usr/netscape/server/cert-cdnintemet-CA/web-apps/ee/ca/ 

5.  Paste  the  certificate  into  the  value  for  the  keyTransportCert  variable.  Make 
sure  the  certificate  encoding  is  surrounded  by  quotation  marks  and  there  are  no 
carriage  returns 
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6.  Save  the  file. 

7.  Repeat  these  steps  on  the  computer  hosting  the  RA  replacing  ra  for  ca  in  the 
directory  location. 
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Chapter 


User  Certificates 


Ceri^uate-  L^-Q/de  Impkmmiabm 

This  chapter  will  define  the  certificate  life-cycle  process  and  how  to  perform  the  tasks 
associated  with  requesting,  issuing,  revoking  and  renewing  certificates. 

Certificate  issuance 

The  certificate  issuance,  approval,  retrieval,  and  renewal  portions  of  this  chapter  use 
the  interfaces  of  the  RA.  They  can  also  be  performed  using  the  interfaces  from  the 
CA  with  the  correct  fully  quahfied  domain  name  and  port  numbers. 

Owner  Request 

1.  On  the  user  machine  go  to  the  end  entity  interface  located  at 
https:, ‘'/cdntestcs.nDs.naw.mil:1037/ra 

2.  Select  the  Manual  User  Dual-Use  Certificate  Enrollment  Form 

3.  FiU  in  the  information  for  the  PKCS  10  request  If  you  are  using  Internet 
Explorer  to  generate  the  keys,  select  one  of  the  three  Microsoft  Cryptographic 
Providers. 
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Requast  Approval 

1 .  To  check  the  status  of  the  certificate  request  you  must  go  to  the  RA  Agent  Interface 
at  httns'  .cdntest.cs.navv.mifHSlKl/raindex.html. 

2.  Select  List  Requests  from  the  left  hand  menu. 

3.  Click  Find. 

4.  Click  Details  next  to  your  request 

5.  Look  over  your  certificate  for  accuracy.  Change  any  information  that  does  violate 
the  constraints  of  that  certificate  profile  as  needed.  Scroll  to  the  bottom  and  tab  down 
to  Accept  Request  (should  be  default  button)  and  Click  Do  It 

6.  The  certificate  request  will  be  returned  with  a  request  identifying  number. 


Owner  Retrieval 

1 .  On  the  owner’s  workstation,  click  the  Retrieval  tab  at 
https  ://'cdntest.cs.  nps.navv.mil:  1 037/ra. 
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2.  Enter  the  request  identifying  number  provided  {ind  click  Submit 
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3.  The  foim  will  return  with  a  status  complete  page  with  the  request  number  and  the 
issued  certificate  number  hyperlinked  to  the  certificate. 


4.  Click  the  issued  certificate  number. 

5.  ScroU  down  and  view  the  certificate.  If  accurate,  chck  import  certificate. 
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Revocation 

There  are  two  possible  methods  for  certificate  revocation,  owner  and  agent.  Owner 

revocation  is  done  through  the  SSL  end-entity  page  of  either  the  RA  or  CA.  Agent 

revocation  is  done  through  the  agent  interface  of  the  C  A. 

Owner  Revocation 

1 .  Go  to  the  SSL  end-entity  interface  for  either  the  RA  at 
httDs://cdntest  cs.nDS.navv.mil:  103 7  or  the  CA  at 
https://cdmntemetcs.nps.navy.mil:  1 027. 

2.  Click  on  the  Revocation  tab. 

3.  The  User  Certificate  Revocation  form  is  the  defeult  document  shown  in  the 
window. 

4.  Select  a  reason  for  revoking  the  certificate.  Click  Submit 
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5.  Select  ihe  certificale  you  wish  to  revoke  from  the  list  in  the  window'  that  pops  up. 
Click  OK. 

6.  The  Certificate  Revocation  Confirmation  page  will  then  appear  with  the  details  of 
the  certificate  you  selected.  Fill  out  any  additional  information  and  click  Submit. 
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7.  A  message  will  then  appear  that  the  revocation  has  been  completed  and  you  will 
receive  an  email  notification  of  the  certificate  revocation. 

Agent  Revocation 

Agent  Revocation  can  only  be  done  through  the  CA’s  agent  interface.  There  are  two 
methods  that  can  be  used  to  revoke  a  certificate  from  this  interface,  one  is  through  the 
revoke  certificates  link  and  is  used  mainly  for  revoking  laige  quantities  or  by  specific 
characteristics  such  as  vahdity  dates.  Upon  completion  of  at  least  one  section  of  this 
form,  a  list  of  certificates  that  meet  the  criteria  specified  will  be  displayed  including 
the  details  and  revoke  buttons.  The  second  method  is  through  the  List  Certificates  link 
in  the  agent  interface,  where  a  details  button  and  a  revoke  button  will  appear  for  those 
certificates  the  CA  can  revoke.  For  each  method,  the  revoke  button  takes  you  to  the 
agent  revocation  page.  This  section  will  describe  method  two,  however  the  majority 
of  this  information  can  be  used  for  both  methods. 

1.  Go  to  the  agent  interface  of  the  CA  at  https://cdnintemet.cs.nps.navv.mil:810Q. 

2.  Click  on  List  Certificates. 

3 .  Enter  the  serial  number  of  the  certificate  you  wish  to  revoke.  Chck  Find. 


4.  The  Certificate  Revocation  Confirmation  Page  appears  containing  the  certificate 
details,  an  invalidity  date  area,  an  area  to  select  the  revocation  reason  and  a 
comment  field.  Once  this  information  is  filled  out  click  Submit. 
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5.  The  Certificate  Revocation  Has  Been  Completed  page  will  then  appear.  If  you 
repeat  steps  1  through  3,  the  newly  revoked  certificate  will  have  red  text  indicating 
that  the  certificate  has  been  revoked. 


Installing  CRL 

Cmrently  there  is  a  CRL  checking  issue  with  the  certificates  and  Microsoft  products. 
A  work  aroimd  involves  importing  and  installing  the  CRL  manually. 

1 .  Go  to  the  end  entity  for  the  Ca  at 
https://cdnintemet.cs.nDS.navv.mil:  1027/ca;'index/html 

2.  Click  the  Retrieval  tab. 
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3.  Select  the  Import  Certificate  Revocation  List  on  the  left  side. 

4.  Select  the  radio  button  next  to  Import  the  latest  CRL  to  your  browser. 

5.  Chck  Submit 

6.  Save  the  file  in  the  directory  of  your  choice. 

7.  Locate  the  file  and  right  click. 

8.  Select  Install  CRL. 

9.  An  Import  Wizard  will  appear,  click  Next. 
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10.  On  the  Certificate  Store  window  select  the  defeult  automatically  select  the 
certificates  store  based  on  the  type  of  certificate.  Click  Next. 

11.  The  wizard  will  reply  with  a  status  restating  the  settings  you  choose.  If  satisfied 
cHck  Finish. 
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12.  A  message  box  will  appear  letting  you  know  the  import  was  successful.  Click 
OK. 

Renewal 

1.  The  user  will  receive  an  email  stating  the  certificate  number  that  needs  to  be 
renewed  with  a  URL  hsted. 


2. ChcktheURL. 

3.  Chck  Submit. 
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4,  A  pop  up  box  containing  all  of  the  user  certificates  will  appear.  Highlight  the 
certificate  you  want  to  renew.  Click  OK 

5.  A  renewal  success  page  will  appear  with  a  new  certificate  for  the  same  subject 
name  with  a  not  valid  before  date  equal  to  the  not  valid  after  date  on  the  old  certificate. 
Click  on  the  import  certificate  button  at  the  bottom  of  the  page  to  import  the  new 
certificate  into  your  browser. 


3  CMS  R»new4l  Rcquesl  SucevM  MkrostrfI  Inlernef  Cuptoier 


ffq  f/M  1^  Ffrartn  (ooh  ^ 


•  J  «1  ^  y  s-*  »  B  ^  V 
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Importing  and  Exporting  Certificate  &  Keys 

As  a  user  moves  between  workstations  or  if  an  agent  would  like  to  access  the  agent 
interface  from  a  machine  other  than  the  one  on  which  the  subsystem  resides,  they  must 
be  able  to  export  and  import  their  keys  along  with  their  certificate  to  another  browser. 
The  next  two  sections  will  discuss  how  to  do  this  using  Netscape.  Similar  steps  can  be 
followed  in  Internet  Explorer. 

Export 

1 .  Open  a  browser  window.  On  the  menu  bar,  click  Communicator.  Select  Tools. 
Select  Security  Info. 

2.  Select  Yours  underneath  Certificates. 


3.  Select  the  certificate  you  wish  to  export  and  click  export. 


4.  Enter  the  password  for  the  Communicator  Certificate  DB. 

5.  Enter  the  password  to  protect  the  data  being  exported  Reenter  the  password. 


6.  Enter  the  filename  of  the  pl2  package  and  the  directory  you  wish  to  save  it  in. 
Click  OK. 
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7.  Once  the  export  is  successful,  the  pl2  file  can  be  transferred  to  a  computer  of  your 
choice. 

Import 

1 .  Open  a  browser  window.  On  the  menu  bar,  chck  Communicator.  Select  Tools. 
Select  Security  Info. 

2 .  S  elect  Y ours  underneath  Certificates . 

3 .  Chck  Import  a  Certificate. 


121 


USER  CERTIFICATES 


4.  Select  the  pl21ile  you  wish  to  import. 

5 .  Enter  the  password  for  the  file . 

6.  You  will  receive  a  message  that  your  certificate  has  been  successfully  imported. 
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Server  Certificates 


the  Server  Cer^cdes  cf  the  Suh^skms 

Managing  Certificates 

Managing  Certificates  is  used  to  enable  trust  relationships  with  other  subsystems  in 
your  PKl.  Each  subsystem  should  have  the  root  CA  certificate  hsted  and  the 
certificate  should  be  trusted.  The  other  certificate  hsted  wdl  depend  on  the  subsystem. 

1 .  Open  up  Netscape  Console  for  the  CA. 

2.  ChcktheConfigurahonTab. 

3 .  Chck  on  Netscape  Certificate  Management  System  on  the  left  side. 

4.  Select  the  Encryption  Tab. 

5.  Select  Manage  Certificates. 
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Certificate  Database  Management 


Certificates'^ 


Certificate  Ivlame  ExtoiryDate  Trust  Status 

Builtin  Object  Token:V8ri...|Julv  16, 2036  16:59:59 

Untrusted 

Builtin  Object  Token: Veri...iAugust  01 , 2028  16:59:59 

Untrusted 

Builtin  Object  Token: Veri... /August  01 , 2028  16:59:59 

Untrusted 

Builtin  Object  Token: V8ri.,.iJulv  16, 2036  16:59:59 

Unfrusted 

Builtin  Object  Token: Veri... 'August  01 , 2028  16:59:59 

Untrusted 

Built«  Object  Token: Veri. ..(August  01 , 2028  16;59;69 

Untrusted 

Builtin  Object  Token:Veri.,.jjulv  IB.  203B  16:59:59 

Untrusted 

Builtin  Object  Token: Veri. ..jAugust  01 , 2028  16:59:59 

Untrusted 

Builtin  Object  Token: Veri... 

July  16,  2036  16:59:59 

Untrusted 

Builtin  Object  Token:  Vs... 

August  15, 2020  16:59:00 

Untrusted 

Builtin  Object  Token:Vs.,. 

August  15,  2020  16:59:00 

Untrusted 

Builtin  Object  T oken:  Vs... 

August  15,  2020  16:59:00 

Untrusted 

Builtin  Object  Token;Vs... 

August  16,  2020  16:59:00 

Untrusted 

Builtin  Object  Token:  Vs... 

August  16,  2020  16:59:00 

Untrusted  | 

Builtin  Object  Token:XcB... 

July  11, 2009  09:14.18 

Untrusted 

Builth  Object  T oken:Xce... 

August  15,  2025  12:03:17 

Untrusted  | 

Builtin  Object  Token:Xce... 

August  15,  2025  12:00:56 

Untrusted 

Untrusted 

Builtin  Object  Token:Xce... 

August  15. 2025  12:00:38 

Builtin  Object  Token:Xce... jAugust  15, 2025  12:01:08 

Untrusted 

IcaSigningCert  cert-cdni ..  'May  17,  2006  00:00:00 

Trusted 

ocspSigningCert  cert-cd... 

May  17,  2006  00:00:00 

T  rusted 

|Server-Cert  cert-cdninte. .  May  17,  2006  00:00:00  (Trusted 

6.  Scroll  to  the  bottom  of  the  list  to  view  certificates  associated  with  yorjr  PKI. 

7.  Select  a  certificate  and  click  EditATiew. 

8.  Click  Change  to  Untrusted/Imsted  button  to  modify  the  trust  of  the  certificate. 

Certificate  Setup  Wizard 

The  Certificate  Setup  Wizard  is  used  for  requesting  and  instalhng  server  certificates. 
On  each  subsystem,  the  options  available  for  the  type  of  certificate  to  request  or  install 
listed  in  the  Certificate  Selection  step  depend  on  the  functionality  of  that  subsystem. 
The  steps  below  are  for  issuing  a  new  Transport  Certificate  for  the  DRM.  Theses 
steps  are  similar  for  aU  of  the  certificates  on  all  of  the  subsystems. 

Requesting  a  New  Certificate 

1 .  Open  Netscape  Console  for  the  DRM. 

2 .  S  elect  the  Configuration  T ab. 


124 


SERVER  CERTIFICATES 


3.  Select  Netscape  Certificate  Management  System  on  the  left  side. 

4.  Select  the  Encryption  tab  on  the  tight  side. 

5.  Chck  Certilieate  Setup  Wizard. 

6.  Chck  Next 

7.  Select  Request  a  Certificate. 

8.  Select  the  type  of  certificate  you  wish  to  update  and  chck  Next 
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9.  You  are  then  given  the  options  for  the  Key-Pair  Information. 

a.  To  renew  a  certificate  choose:  Use  existing  key  pair. 

b.  If  the  keys  were  compromised  for  some  reason  or  you  feel  new  keys 
are  needed,  select:  Create  new  key  pair. 


10.  ChckNext 

1 1 .  Generating  the  request 
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a.  If  you  have  selected  Create  a  new  key  pair,  you  will  be  prompted  for 
subject  name  information.  Enter  that  information  and  chck  Next. 

b.  If  you  selected  Use  existing  key  pair,  the  wizard  has  enough 
information  to  generate  the  request  automatically.  Chck  Next. 

1 2.  Enter  the  information  of  the  CA  to  send  the  request  to  and  chck  N  ext. 

13.  The  wizard  will  return  a  request  number  and  you  must  go  to  the  Agent 
Interface  of  the  CA  and  approve  the  request.  Refer  to  the  Request  Approval 
section  in  Chapter  4  of  this  guide. 

14.  Chck  Done. 

Installing  a  New  Certificate 

1 .  Open  Netscape  Console  for  the  DRM. 

2 .  S  elect  the  Conhguration  T ab. 

3.  Select  Netscape  Certificate  Management  System  on  the  left  side. 

4.  Select  the  Encryption  tab  on  the  right  side. 

5.  Chck  Certificate  Setup  Wizard. 

6.  Chck  Next. 

7.  Select  Install  a  certificate  and  chck  Next. 

8.  Select  the  type  of  certificate  you  wish  to  install  and  chck  Next. 

9.  Go  to  the  agent  interfece  of  the  CA  ihttps://cdnintemet.cs.nps.navv.mil:8100y 
Navigate  to  the  certificate  you  just  approved.  Copy  the  base  64  encoding 
including  Begin  Certificate  and  End  Certificate. 

10.  Select  the  certificate  is  located  in  the  text  area  below.  Chck  Paste  from 
Chpboard. 

11.  Chck  Next. 

12.  Chck  Done. 

1 3.  Return  to  Manage  Certificates  and  ensure  that  the  certificate  that  you  just 
installed  is  trusted.  Also  remember  that  you  wdl  have  to  adjust  the 
ProfileSelect.template  files  on  both  the  CA  and  RA  for  key  archival  requests 
(Chapter  2  -  Adding  the  KRA  Transport  Certificate 
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Cfiapter 


Users  and  Groups 

Managr^  Users  and  Grasps 


Users 

Users,  based  on  the  groups  to  which  they  are  assigned,  have  access  to  specific  areas  of 
the  Netscape  Console  and  web  interfaces  of  a  subsystem. 

Add 

1 .  Open  the  console  for  the  subsystem. 

2.  SelectUser  and  Groups.  Chck  Add 
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3.  The  Edit  User  Information  window  will  appear,  add  the  information  needed. 
You  do  not  have  to  enter  a  password,  email  address  or  phone  number.  Select 
the  group  to  which  they  will  belong  initially. 

4.  ChckOK.  Youcanthenedituserinformation  via  the  edit  button. 

5.  Next  you  need  to  add  the  user’s  certificate  to  the  user  information  for 
authentication  purposes. 

6.  Select  the  User  and  chck  Certificates. 


7.  Selectthe  Importkey. 

8.  Go  the  CA  end-entity  interface  at:  httos://cdnintemet.cs.nDs.naw.mil:1027/ca 

9.  Chck  the  Retrieval  tab. 

1 0.  Go  to  List  Certificates  and  enter  the  certificate  number  or  chck  Find.  Select  the 
certificate  associated  with  this  user. 
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12.  Return  to  the  Import  Certificate  window  and  click  Paste  from  clipboard.  Click 
OK. 

13.  The  certificate  will  appear  in  the  Manage  User  Certificates  window.  Chck 
View  to  view  the  certificate  if  desired  and  then  chck  Done. 


Delete 

1 .  Open  the  console  window  for  the  subsystem . 

2.  SelectUsers  and  Groups.  Select  the  user  you  want  to  remove  and  chck  Delete 


3.  A  warning  message  whl  appear  verifying  you  want  to  remove  a  user.  Chck 
Yes. 


Groups 

Add 

1 .  Open  the  console  window  for  the  subsystem.  Select  Users  and  Groups. 

2.  Chck  on  the  Groups  tab.  Users  is  the  default  selechon.  Select  the  Add  key. 
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Edit  Group  Information 


Group  name:  Administrators 

Group  description:  1 5  Netscape  Certificate  Management  Systenn 
Group  Members; 


amkelly  Dl 

Add  User  | 

1  zl 

Delete  | 

OK  I  Cancel  |  Help  | 


3.  An  Edit  Group  Infomiation  window  will  pop  up.  Add  the  needed  mformation 
to  include  the  user  associated  with  the  group.  Click  OK 


Delete 

1 .  Open  the  console  window  for  the  subsystem.  Select  Users  and  Groups. 
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2.  Click  on  the  lab  for  Groups.  Select  ihe  group  you  want  to  remove  and  click 
Delete. 


3.  A  warning  message  will  appear  verifying  you  want  to  remove  the  selected 
grotfli.  (Mick  Yes. 
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Notification  and  Jobs 


Ip  n^iions  andjok 


Sotting  Up  the  Mail  Server 

1  Open  up  the  console  for  the  CA. 

2.  In  the  left  hand  panel  select  Netscape  t’ertificate  Management  System. 


3.  In  the  nghi  hand  panel  click  the  SMTP  tab. 
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4.  Enter  the  email  server  and  port  number. 


5.  Click  Save. 

6.  This  should  be  repeated  for  the  RA  as  well. 

Enabling  Notifications 

1 .  In  the  console,  expand  the  hst  under  Certificate  Manager. 

2.  Select  Notification. 

3.  There  are  three  possible  notifications  fisted:  Certificate  Issued,  Certificate 
Revoked,  and  Request  in  Queue. 
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cdnintefnetnjt>wvv.mil  -  HtwuK  Ccftiflme  itoaymgit  Synem  •  cdninte  met-q 


Coviato  ra  vio 


Nojope  Ceac*  Mcragowt  $««■ 


TMti  I  SWut 


4.  For  each  notification  select  its  tab.  click  the  enable  box.  and  enter  in  the 
information  needed.  To  have  a  notification  go  to  more  than  one  user  separate 
tile  email  addresses  by  commas. 


5.  CMick  Save  for  each  tab. 

ITiis  can  be  repeated  for  the  RA  as  well,  by  replacing  Certificate  Manager  with 
Registration  Manager,  'fhe  R.4  only  has  the  Certificate  Issued  and  Request  in  Queue 
notifications  since  it  does  not  have  the  authoritv  to  revoke  certificates. 


Job  Scheduler  &  Jobs 

1.  To  U.SC  Jobs,  you  mast  first  enable  the  Job  Scheduler  by  selecting  Job 
Scheduler  on  the  left  hand  side  of  tlie  console. 
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2.  Check  the  Enable  Jobs  Scheduler  box. 

3.  Enter  the  frequency  in  minutes  that  the  scheduler  should  eheek  for  awaiting 
jobs  to  be  processed. 

4.  Expand  the  Job  Scheduler  on  the  left  side  panel. 
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cdnlnt<fn<t«np;  navy  mil  -  H<?t;capgC<rntlcat<  K<dnaym»nt$yiTgm  -  c4nint<mer-CA 


IcoraOi  Efl  I 


5,  Select  Jobs.  From  here  you  can  either  add  or  delete  a  job  instance  or  edit/view 
an  existing  job  instance. 

6.  To  edit  a  Job  instance  click  the  EditA^iew  button.  A  window  will  appear  with 
blank  fields.  Input  the  required  information. 
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7.  CHckOK. 
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Chapter 


Certificate  Profiles 


Certificate  Profiles  are  used  by  the  CA  and  the  RA  for  the  creation  of  certificates  for 
your  organization.  Each  profile  can  be  setup  for  a  specific  type  of  user  or  system.  The 
profiles  contain  certificate  extension  information  and  the  inputs  and  outputs  required 
for  that  type  of  enrollment.  Once  a  profile  has  been  created,  an  HTML  page  is  created 
for  the  end-entity  interface.  A  user  can  then  access  that  enrollment  page  for  that 
certificate  profile  by  selecting  it  in  the  Enrollment  Tab.  This  chapter  discusses  the 
management  of  Certificate  Profiles. 

Approve  or  Disable  a  Profile 

1 .  Open  a  browser  to  the  agent  interfece  of  the  CA. 
https :  //cdnintemet  cs  .nps  .naw.  mil:  8 1 00 

2.  Chck  Manage  Certificate  Profiles 

3.  Select  a  Profile. 

4.  At  the  bottom  of  the  page  is  either  an  Approve  or  a  Disable  button.  This 
toggle  button  allows  for  a  profile  to  be  approved,  meaning  that  it  is  accessible 
via  the  end-entity  interlace,  or  disabled,  meaning  that  it  is  not  accessible  from 
the  end-entity  page.  A  profile  must  be  disabled  before  an  administrator  can 
modify  it  in  the  Netscape  Console. 

Adding  a  Certificate  Profile 

A  quick  note:  for  certificate  enrollment  initiated  through  the  RA,  the  CA  must  have  a 
copy  of  the  certificate  Profile,  with  the  same  name,  used  by  the  RA.  As  mentioned  in 
step  six  below,  the  profile  for  the  RA  wfil  have  End  User  Certificate  Profile  set  to  true. 
The  same  profile  on  the  CA  wfil  have  End  User  Certificate  Profile  set  to  fMse, 
ensuring  that  the  request  does  not  have  to  be  processed  via  the  input  form  associated 
with  that  profile  on  the  CA. 

1 .  Open  the  N  etscape  Console  of  the  CA. 
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2.  Expand  the  Certificate  Manager  list  on  the  left  side. 

3.  Select  Certificate  Profiles. 

4.  Click  Add  under  the  Certificate  Profile  Instances  Management  tab. 


-J _ cdninternet.cs.nps.nav^,mil  -  Netscape  Certificate  Management  System  -  cdninternet-CA 

Console  Edit  ^ew  ^fc}eot  Help 


5.  Select  Certificate  Authority  Enrollment  Profile  and  click  Next. 

6.  Enter  the  information  requested  and  click  OK. 

a.  Ifthisprofileis  tobeusedonlyby  the  CA,  End  User  Certificate 
Profile  should  be  set  to  true. 

b.  If  this  profile  is  a  duplicate  of  a  profile  that  will  be  used  by  the  RA, 
then  EndUser  Certificate  Profile  should  be  set  to  false.  In  the  same 
profile  on  the  RA  this  value  will  be  set  to  true. 
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7.  The  profile  will  then  appearin  the  profile  instance  fist  and  is  ready  to  be 
configured  using  the  EdihView  button.  Select  the  profile  and  chck  Edit 

8.  Select  the  Pohcies  tab  and  chck  Add.  A  fist  of  possible  certificate  extensions 
wfil  appear.  For  each  extension  needed  by  for  this  certificate  type,  repeat  the 
following  steps.  For  more  information  on  Certificate  Extensions  go  to  the 
Administrator’s  Guide,  Netscape  Certificate  Management  System,  Version 
6.1,  page  717. 

a.  Select  the  Extension. 

b.  Select  No  Constraint  or  Extension  Constraint.  Only  one  choice  may 
appear  in  the  bottom  porhon  of  the  window,  in  that  case  select  the 
defeult  Each  extension  can  have  different  constraint  possibihties. 
Refer  to  the  Administrator’s  Guide  listed  above  for  more  informahon. 

c.  Chck  OK. 
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d.  Enter  a  PoKcy  Set  Id  and  a  Policy  Id. 

e.  Fill  out  the  information  relevant  for  the  extension  under  the  Default 
and  Constraint  tabs.  Chck  OK  when  finished. 


9.  Select  the  Inputs  tab  and  chck  Add.  Select  on  of  the  six  possible  inputs  and 
chck  OK. 


as 


143 


CERT 


FICATE  PROFILES 


a.  Enter  the  Id  and  click  OK 

b .  Repeat  for  all  of  the  inputs  required. 

1 0.  Chck  on  the  Outputs  tab.  Currently,  there  is  only  one  possible  output.  Select 
Certificate  Output,  enter  the  Id  and  click  OK. 

11.  Chck  OK. 

1 2.  Return  to  the  agent  interlace  of  the  CA. 

13.  Chck  Manager  Certificate  Profiles. 

14.  Selectthe  profile  you  just  added. 

1 5.  Chck  Approve.  The  profile  is  now  available  for  certificate  enrollment  by  the 
user. 

Editing  a  Certificate  Profile 

1 .  Complete  the  steps  in  Approve  or  Disable  a  Profile  above  to  disable  the  profile 
you  wish  to  edit  A  profile  must  be  disabled  to  be  modified. 

2.  Open  the  Netscape  Console  of  the  CA. 

3 .  Expand  the  Certificate  Manager  fist  on  the  left  side. 

4 .  S  elect  Certificate  Profiles . 

5.  Select  the  profile  you  wish  to  edit  and  chck  EditA'iew. 

6.  At  the  Policies,  Inputs,  and  Outputs  tabs,  you  can  delete  or  edit  any  of  the  Ids 
currently  fisted  or  you  can  add  anew  Id. 
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7.  Click  OK  when  you  are  finished  making  modifications. 

8.  Repeat  step  1 ,  to  approve  the  profile. 

Deleting  a  Profile 

1 .  Complete  the  steps  in  Approve  or  Disable  a  Profile  above  to  disable  the  profile 
you  wish  to  edit.  A  profile  must  be  disabled  to  be  deleted. 

2.  Select  the  profile  you  wish  to  delete. 

3 .  Click  the  Delete  button. 

4.  You  will  be  prompted  “Are  you  sure  you  wish  to  delete  this  profile?”  Chck 
Yes. 


PUBLISHING  AND  CRL  ISSUING  POINTS 


Publishing  and  CRL  Issuing 
Points 


EnaMngandew^gmrgpHlislingimi  CELAmv^Pomts 

The  Certificate  Authority  is  the  sole  authority  of  the  CRL  in  CMS  PKI.  Only  CA 
agents  can  revoke  certificates  and  only  CA  administrators  have  the  authority  to 
configure  CRL  issuing  points  and  enable  CRL  pubhshing  to  the  Directory  Server. 

Configuring  the  CRL  Issuing  Point 

1 .  Open  Netscape  Console  for  the  CA. 

2.  Expand  the  Certificate  Manager  List. 

3.  Expand  the  CRL  Issuing  Points.  If  you  select  CRL  Issuing  Points,  a  list  of 
CRL  issuing  points  will  be  displayed.  From  here  you  can  add,  edit,  or  delete 
an  issuing  point. 

a.  To  Add 

i.  Click  Add 

ii.  Check  enable 

hi.  Enter  the  name  and  description  of  the  issuing  point 
iv.  CHckOK 

b.  To  Edit 

i.  Click  Edit 

h.  Check  or  uncheck  enable 

hi .  Modify  the  description  if  needed. 
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iv.  Click  OK 
c.  To  Delete 

i.  Select  the  Issuing  Point  you  want  to  delete, 
h.  Click  Delete, 
in.  Click  Yes. 

4.  Select  the  Issuing  Point.  From  here  you  can  modify  the  update  frequency,  the 
CRL  cache  information,  and  the  CRL  format.  After  making  any  needed 
changes,  click  Save  to  apply  them. 


5.  Expand  the  Issuing  Point. 

6.  Select  CRL  Extensions. 
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7.  Select  the  extension  you  wish  to  modify.  Chck  EditA^iew. 

a.  Check  or  uncheck  enable. 

b.  Check  or  uncheck  critical. 

c.  Add  or  modify  other  information  relevant  to  that  particular  extension. 
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Publishing 

Enabling  publishing  allows  certificates  and  the  CRL  to  be  pubhshed  to  the  Directory 
Server  allowing  for  LDAP  connections  to  retrieve  that  information. 

1 .  Open  Netscape  Console  for  the  CA. 

2.  Expand  the  Certificate  Manager  hst 

3 .  S  elect  Pubhshing. 

a.  Chck  Enable  Pubhshing. 

b.  Chck  Enable  Default  LDAP  Connection  and  enter  in  the  information 
for  the  Directory  Server  Instance  (cdnintemet-CA-db)  in  the  CA’s 
server  group. 
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c.  Click  Save.  A  series  of  Java  communicatioas  are  performed  with  the 
Directory  Server.  If  all  of  the  tests  were  successful  then  the  following 
image  will  appear.  If  the  tests  were  not  successful  and  an  error 
occurred  you  will  need  to  check  the  log  files  (Select  the  Status  tab, 
expand  the  log  list,  select  sj'stem)  to  determine  what  the  error  was. 


There  are  three  more  components  to  publishing;  mappers,  publishers,  and  rules.  They 
can  be  added,  configured  and  deleted  as  needed.  The  default  values  installed  in  those 
components  during  the  initial  insUillation  did  not  require  modification  for  this  thesis. 
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For  more  information  on  publishing  refer  to  Administrator’s  Guide  Netscape 
Certificate  Management  System,  Version  6.1,  page  617. 
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Key  Archival  and  Recovery 


Key  Archival 

Assuming  that  all  of  your  trust  relationships,  trusted  managers,  users,  and 
Profiles  elect. templates  are  setup  up  correctly,  key  archival  should  be  a  simple  process 
that  occurs  during  certificate  request.  The  certificate  owner  must  generate  the  request 
from  a  Netscape  7. 1  browser  or  higher  and  the  key  generation  tjqre  must  say  CRMF. 
Once  the  request  is  made,  the  owner  will  be  prompted  to  approve  the  transport  of  their 
private  key,  encrypted  by  the  DRM  Transport  Certificate.  Once  the  certificate  is 
created,  the  keys  and  certificate  wiU  be  sent  to  the  DRM  for  storage.  This  information 
is  stored  in  the  Directory  Server  of  the  DRM,  encrypted  by  its  Storage  Certificate.  At 
the  time  of  this  writing,  there  is  a  problem  with  the  trust  relationships  between  the  CA 
and  DRM,  so  key  archival  is  inoperable.  Therefore  no  other  information  on  it  can  be 
provided.  Below  is  the  key  archival  process  as  described  in  the  Administrator’s 
Guide. 
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Key  Recovery  Scheme 

Archived  keys  remain  encrypted  until  key  recovery  agents  use  passwords  to  unlock 
the  password-spHtting  mechanism.  The  Administrator’s  Guide  states: 

For  the  protection  of  the  storage  key  pair,  the  Data  Recovery 
Manager  supports  a  password-splitting  mechanism  called  m  n  secret 
splitting  or  sharings  whereby  it  splits  the  PIN  that  protects  the  token  in 
which  the  storage  key  pair  resides  among  n  number  of  key  recovery 
agents  and  reconstructs  the  PIN  only  if  m  number  of  recovery  agents 
provide  their  individual  passwords;  n  must  be  an  integer  greater  than 
1  and  m  must  be  an  integer  less  than  or  equal  to  no 

During  the  DRM  subsystem  installation,  the  administrator  selects  the  m  of  n  scheme, 
where  m  is  the  number  of  recovery  agents  required  to  unlock  the  storage  key  and  n  is 
the  number  of  possible  recovery  agents  as  seen  below.  Both  the  scheme  and  the 
recovery  agents’  passwords  can  be  modified. 


Scheme  Management 

1 .  Open  Netscape  Console  of  the  DRM . 

2.  Select  the  Configuration  tab. 

3.  Select  Data  Recovery  Manager  on  left  side. 

4.  Select  Scheme  Management  tab  on  right  side. 


^  Administrator's  Guide,  Netscape  Certificate  Management  System  Version  6.1,  Feb  2003,  pg  206. 
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5.  Click  Change  scheme. 

6.  Enter  the  new  numbers  for  number  of  recovery  agents  required  and  total 
number  of  recovery  agents. 


7.  ChckNext. 

8.  Enter  current  recovery  agent  UIDs  and  passwords. 

9.  ChckNext 

1 0.  Enter  the  UIDs  and  passwords  for  ah  of  the  available  recovery  agents . 
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11.  CUckNext. 

1 2.  Click  Done. 

Changing  Recovery  Agent  Passwords 

1 .  Open  Netscape  Console  of  the  DRM. 

2.  Select  the  Configuration  tab. 

3.  Select  Data  Recovery  Manager  on  left  side. 

4.  Select  Recovery  Agent  Password  tab  on  right  side. 

5.  Select  the  Recovery  Agent  for  whom  you  would  like  to  change  the  password. 

6.  Chck  Change  password 

7.  Enter  old  password  and  the  new  password  twice. 

8.  Chck  OK. 

Note:  Changing  the  recovery  agent  passwords  should  be  done  directly  after  the 
installation  of  the  DRM  and  on  a  recurring  basis  (every  6  months)  after  that  There 
should  also  be  a  pohcy  on  the  composition  of  the  passwords  (length,  numbers,  letters, 
case,  etc). 
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Key  Recovery 

The  agent  interface  is  used  for  key  recovery  prrrposes.  There  are  two  forms  of  key 
recovery  authorization  available  in  CMS,  local  and  remote.  The  CISR  PKI  is 
currently  configirred  for  local  authorization. 


Local  authorization  requires  the  Key  Recovery  agents  to  be  on  the  computer  hosting 
the  DRM.  If  the  correct  passwords  are  entered,  via  the  agent  interface,  by  the  required 
number  of  recovery  agents,  then  the  DRM  retrieves  the  key  and  returns  the  key  and 
its  corresponding  certificate  in  a  PKCS  #12  package.  Remote  Authorization  is 
initiated  by  one  recovery  agent.  Once  the  recovery  request  is  initiated,  the  DRM  sends 
an  email  with  a  specific  reference  number  to  aU  of  the  other  recovery  agents.  The 
reqrrired  number  of  agents  must  individually  access  the  DRM’s  agent  interface  and 
using  the  reference  number  authorizes  the  key  recovery.  The  PKCS  #12  package 
containing  the  key  and  its  certificate  are  returned  to  the  recovery  agent  initiating  the 
request.  The  agent-initiated  key  recovery  process  is  pictrrred  below. 
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Data  Recovery  Manager 
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